Page 1 of 1

Editor strings representation

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

Господа, у меня возникла внезапная идея - а не хранить ли нам в памяти строки редактора как utf-8 char*, переводя их в wchar_t* только для отображения и для ECTL_GETSTRING?
Вроде ничего отвалиться не должно, а на ascii-данных (коих большинство) экономия в два раза. Или я что-то очевидное упускаю?

Editor strings representation

Posted: Wed 22 Feb, 2017 23:08
by Shmuel
Меня и нынешняя ситуация устраивает. Хотя если ничего не сломается, то всё равно.
ECTL_GETSTRING, который сейчас просто отдаёт указатель, замедлится в разы, но вряд ли это будет сильно заметно в общей картине.

Editor strings representation

Posted: Wed 22 Feb, 2017 23:23
by 2useven10
А стоит ли овчинка? Чтобы ничего не сломалось - это фантастика.
И если всё-таки переделывать, я бы просто хранил строку в ACP, если можно,
или как сейчас, если в ACP не влезет, чтобы не возиться постоянно с переменно длинным UTF-8.

Editor strings representation

Posted: Wed 22 Feb, 2017 23:35
by HaRT
DrKnS wrote: переводя их в wchar_t* только для отображения и для ECTL_GETSTRING
Неплохо бы оценить, как это повлияет на скорость поиска/замены/фильтрации в RESearch/EdtFind/LuaFarSearch/…

Editor strings representation

Posted: Wed 22 Feb, 2017 23:37
by HaRT
DrKnS wrote: на ascii-данных (коих большинство) экономия в два раза
А теперь представим себе какой-нибудь дамп большой БД на каком-нибудь азиатском языке — вместо выигрыша получим ощутимый проигрыш.

Editor strings representation

Posted: Wed 22 Feb, 2017 23:46
by DrKnS
2useven10 wrote: А стоит ли овчинка?
Понятия не имею, отсюда и вопрос залу.
Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.

Editor strings representation

Posted: Thu 23 Feb, 2017 10:08
by ctapmex
памяти то конечно сэкономит. проигрыш в скорости будет не значительным. можно накидать небольшой бенчмарк сколько займет времени преобразование файла из одной кодировки в другую.
есть такое движение http://utf8everywhere.org/

Editor strings representation

Posted: Thu 23 Feb, 2017 11:12
by zg
пробовать можно уже сейчас. в макросах обратное преобразование, не думаю, что разница в скорости utf8->utf16 и utf16->utf8 значительная. так вот можно ту же подсветку сравнить. на длинных строках. с табами.
я против. память нужно один раз докупить, тормоза - всё время.

Editor strings representation

Posted: Thu 23 Feb, 2017 15:01
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 ════╝

Editor strings representation

Posted: Sat 25 Feb, 2017 11:13
by Freeman
DrKnS wrote:Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
По логике, дампы связаны с серверами, а для серверов и/или рабочих мест для их обслуживания сам бог велел докупить памяти.
zg wrote:память нужно один раз докупить, тормоза - всё время.
Верно!

Editor strings representation

Posted: Sun 26 Feb, 2017 18:51
by cmd.exe
Проблем в сравнении с переходом неувидел. Дальше оффтопик.
Редактор очень тормозит при загруженом Colorer+LuaMacro. Проверял на логе в 16к. Луа, при редоктировании макросом больших файлов жрёт ресурсы. Колорер бывает необоснованно долго раскрашивает, при этом ресурсы кушает.
Использую airbrush, он хоть и кеширует себя в память, в первый раз долго, хато работает очень шустро.
Приходится таскать 2-е сборки фара, одна шустрая, другая имеет удобные плагины.