Editor strings representation

Разработка Far.
Post Reply
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Editor strings representation

Post by DrKnS »

Некоторые жалуются, что редактор весьма жаден до памяти по сравнению с Far 1.7 (в 2 раза как минимум) и теперь якобы неудобно редактировать всякие жирные дампы и т. п.
Это не лишено оснований, т. к. wchar_t в те же два раза больше char.

Господа, у меня возникла внезапная идея - а не хранить ли нам в памяти строки редактора как utf-8 char*, переводя их в wchar_t* только для отображения и для ECTL_GETSTRING?
Вроде ничего отвалиться не должно, а на ascii-данных (коих большинство) экономия в два раза. Или я что-то очевидное упускаю?
Shmuel
Posts: 6815
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 41 times
Been thanked: 526 times

Editor strings representation

Post by Shmuel »

Меня и нынешняя ситуация устраивает. Хотя если ничего не сломается, то всё равно.
ECTL_GETSTRING, который сейчас просто отдаёт указатель, замедлится в разы, но вряд ли это будет сильно заметно в общей картине.
2useven10
Posts: 5192
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 309 times

Editor strings representation

Post by 2useven10 »

А стоит ли овчинка? Чтобы ничего не сломалось - это фантастика.
И если всё-таки переделывать, я бы просто хранил строку в ACP, если можно,
или как сейчас, если в ACP не влезет, чтобы не возиться постоянно с переменно длинным UTF-8.
User avatar
HaRT
Moderator
Posts: 10806
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 220 times
Been thanked: 357 times

Editor strings representation

Post by HaRT »

DrKnS wrote: переводя их в wchar_t* только для отображения и для ECTL_GETSTRING
Неплохо бы оценить, как это повлияет на скорость поиска/замены/фильтрации в RESearch/EdtFind/LuaFarSearch/…
Last edited by HaRT on Wed 22 Feb, 2017 23:35, edited 1 time in total.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
HaRT
Moderator
Posts: 10806
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 220 times
Been thanked: 357 times

Editor strings representation

Post by HaRT »

DrKnS wrote: на ascii-данных (коих большинство) экономия в два раза
А теперь представим себе какой-нибудь дамп большой БД на каком-нибудь азиатском языке — вместо выигрыша получим ощутимый проигрыш.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

Editor strings representation

Post by DrKnS »

2useven10 wrote: А стоит ли овчинка?
Понятия не имею, отсюда и вопрос залу.
Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
User avatar
ctapmex
Posts: 1240
Joined: Fri 11 Apr, 2008 07:53
Has thanked: 1 time
Been thanked: 50 times

Editor strings representation

Post by ctapmex »

памяти то конечно сэкономит. проигрыш в скорости будет не значительным. можно накидать небольшой бенчмарк сколько займет времени преобразование файла из одной кодировки в другую.
есть такое движение http://utf8everywhere.org/
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Editor strings representation

Post by zg »

пробовать можно уже сейчас. в макросах обратное преобразование, не думаю, что разница в скорости utf8->utf16 и utf16->utf8 значительная. так вот можно ту же подсветку сравнить. на длинных строках. с табами.
я против. память нужно один раз докупить, тормоза - всё время.
User avatar
zg
zero-gravity
Posts: 6015
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 185 times
Contact:

Editor strings representation

Post by zg »

я провёл тест. код:

Code: Select all

local ffi=require("ffi")
local C=ffi.C
local ec=ffi.cast("struct PluginStartupInfo*", far.CPluginStartupInfo()).EditorControl
local egs=ffi.new("struct EditorGetString")
egs.StructSize=ffi.sizeof(egs)
local function GetDirect(id,lineno)
  egs.StringNumber=lineno-1
  ec(id,"ECTL_GETSTRING",0,egs)
end

local function GetLua(eid,lineno)
  editor.GetString(eid,lineno,3);
end


local function bench(f)
  local ei=editor.GetInfo()
  local eid=ei.EditorID
  local start=far.FarClock()
  for ii=1,ei.TotalLines do f(eid,ii) end
  local time=far.FarClock()
  return (time-start)/10^6
end

MenuItem{
  guid="c9fa33bf-7bcf-4533-b09c-384e661e4abe";
  menu="Plugins";
  area="Editor";
  text="~bench~";
  action=function()
    fast,slow=bench(GetDirect),bench(GetLua)
    far.Show(fast,slow,slow/fast)
  end
}
результат на far.map (минимальный из 10 прогонов):

Code: Select all

╔═════════════════════╗
║  1│ 0.025877        ║
║  2│ 0.139132        ║
║  3│ 5.3766665378521 ║
╚════ 3 arguments ════╝
т.е. в простой ситуации (отрисовка+красящий плагин) в 10 раз медленнее. если есть какое-то автодополнение — в 15. учитывая то, что редактор не всегда отрисовывается только когда нужно — ещё больше. можно наверное закешировать, но опять же тому же автодополнению не особо поможет.

update: сам луа вносит дополнительный оверхед, уменьшить влияние которого можно, увеличив длину строк (ну или плагин написать, но это мне уже лень). на файле с 5k строками так:

Code: Select all

╔═════════════════════╗
║  1│ 0.033097        ║
║  2│ 1.426834        ║
║  3│ 43.110674683506 ║
╚════ 3 arguments ════╝
Last edited by zg on Thu 23 Feb, 2017 15:42, edited 1 time in total.
User avatar
Freeman
Posts: 35
Joined: Thu 20 Nov, 2014 20:10
Location: Санкт-Петербург
Has thanked: 5 times
Been thanked: 2 times
Contact:

Editor strings representation

Post by Freeman »

DrKnS wrote:Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
По логике, дампы связаны с серверами, а для серверов и/или рабочих мест для их обслуживания сам бог велел докупить памяти.
zg wrote:память нужно один раз докупить, тормоза - всё время.
Верно!
Пользователь Far с 1998 года
User avatar
cmd.exe
Posts: 378
Joined: Fri 16 Apr, 2010 18:26
Location: Нижний Новгород
Has thanked: 181 times
Been thanked: 10 times
Contact:

Editor strings representation

Post by cmd.exe »

Проблем в сравнении с переходом неувидел. Дальше оффтопик.
Редактор очень тормозит при загруженом Colorer+LuaMacro. Проверял на логе в 16к. Луа, при редоктировании макросом больших файлов жрёт ресурсы. Колорер бывает необоснованно долго раскрашивает, при этом ресурсы кушает.
Использую airbrush, он хоть и кеширует себя в память, в первый раз долго, хато работает очень шустро.
Приходится таскать 2-е сборки фара, одна шустрая, другая имеет удобные плагины.
I've been using Vim for about 2 years now, mostly because I can't figure out how to exit it. (c) I Am Devloper
I know nothing except the fact of my ignorance. (с) Socrates
Post Reply

Return to “Development”