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-е сборки фара, одна шустрая, другая имеет удобные плагины.