Editor strings representation
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Editor strings representation
Некоторые жалуются, что редактор весьма жаден до памяти по сравнению с Far 1.7 (в 2 раза как минимум) и теперь якобы неудобно редактировать всякие жирные дампы и т. п.
Это не лишено оснований, т. к. wchar_t в те же два раза больше char.
Господа, у меня возникла внезапная идея - а не хранить ли нам в памяти строки редактора как utf-8 char*, переводя их в wchar_t* только для отображения и для ECTL_GETSTRING?
Вроде ничего отвалиться не должно, а на ascii-данных (коих большинство) экономия в два раза. Или я что-то очевидное упускаю?
Это не лишено оснований, т. к. wchar_t в те же два раза больше char.
Господа, у меня возникла внезапная идея - а не хранить ли нам в памяти строки редактора как utf-8 char*, переводя их в wchar_t* только для отображения и для ECTL_GETSTRING?
Вроде ничего отвалиться не должно, а на ascii-данных (коих большинство) экономия в два раза. Или я что-то очевидное упускаю?
-
- Posts: 6840
- Joined: Thu 23 Mar, 2006 21:36
- Location: Israel
- Has thanked: 41 times
- Been thanked: 530 times
Editor strings representation
Меня и нынешняя ситуация устраивает. Хотя если ничего не сломается, то всё равно.
ECTL_GETSTRING, который сейчас просто отдаёт указатель, замедлится в разы, но вряд ли это будет сильно заметно в общей картине.
ECTL_GETSTRING, который сейчас просто отдаёт указатель, замедлится в разы, но вряд ли это будет сильно заметно в общей картине.
Editor strings representation
А стоит ли овчинка? Чтобы ничего не сломалось - это фантастика.
И если всё-таки переделывать, я бы просто хранил строку в ACP, если можно,
или как сейчас, если в ACP не влезет, чтобы не возиться постоянно с переменно длинным UTF-8.
И если всё-таки переделывать, я бы просто хранил строку в ACP, если можно,
или как сейчас, если в ACP не влезет, чтобы не возиться постоянно с переменно длинным UTF-8.
- HaRT
- Moderator
- Posts: 10866
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
Editor strings representation
Неплохо бы оценить, как это повлияет на скорость поиска/замены/фильтрации в RESearch/EdtFind/LuaFarSearch/…
Last edited by HaRT on Wed 22 Feb, 2017 23:35, edited 1 time in total.
Фар есть инструмент, а не нянька. © 2009 DrKnS
- HaRT
- Moderator
- Posts: 10866
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
Editor strings representation
А теперь представим себе какой-нибудь дамп большой БД на каком-нибудь азиатском языке — вместо выигрыша получим ощутимый проигрыш.
Фар есть инструмент, а не нянька. © 2009 DrKnS
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Editor strings representation
Понятия не имею, отсюда и вопрос залу.
Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
Editor strings representation
памяти то конечно сэкономит. проигрыш в скорости будет не значительным. можно накидать небольшой бенчмарк сколько займет времени преобразование файла из одной кодировки в другую.
есть такое движение http://utf8everywhere.org/
есть такое движение http://utf8everywhere.org/
- zg
- zero-gravity
- Posts: 6036
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Editor strings representation
пробовать можно уже сейчас. в макросах обратное преобразование, не думаю, что разница в скорости utf8->utf16 и utf16->utf8 значительная. так вот можно ту же подсветку сравнить. на длинных строках. с табами.
я против. память нужно один раз докупить, тормоза - всё время.
я против. память нужно один раз докупить, тормоза - всё время.
- zg
- zero-gravity
- Posts: 6036
- Joined: Tue 15 Mar, 2005 17:36
- Location: riga
- Been thanked: 185 times
- Contact:
Editor strings representation
я провёл тест. код:
результат на far.map (минимальный из 10 прогонов):
т.е. в простой ситуации (отрисовка+красящий плагин) в 10 раз медленнее. если есть какое-то автодополнение — в 15. учитывая то, что редактор не всегда отрисовывается только когда нужно — ещё больше. можно наверное закешировать, но опять же тому же автодополнению не особо поможет.
update: сам луа вносит дополнительный оверхед, уменьшить влияние которого можно, увеличив длину строк (ну или плагин написать, но это мне уже лень). на файле с 5k строками так:
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
}
Code: Select all
╔═════════════════════╗
║ 1│ 0.025877 ║
║ 2│ 0.139132 ║
║ 3│ 5.3766665378521 ║
╚════ 3 arguments ════╝
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.
- Freeman
- Posts: 35
- Joined: Thu 20 Nov, 2014 20:10
- Location: Санкт-Петербург
- Has thanked: 5 times
- Been thanked: 2 times
- Contact:
Editor strings representation
По логике, дампы связаны с серверами, а для серверов и/или рабочих мест для их обслуживания сам бог велел докупить памяти.DrKnS wrote:Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
Верно!zg wrote:память нужно один раз докупить, тормоза - всё время.
Пользователь Far с 1998 года
- cmd.exe
- Posts: 378
- Joined: Fri 16 Apr, 2010 18:26
- Location: Нижний Новгород
- Has thanked: 181 times
- Been thanked: 10 times
- Contact:
Editor strings representation
Проблем в сравнении с переходом неувидел. Дальше оффтопик.
Редактор очень тормозит при загруженом Colorer+LuaMacro. Проверял на логе в 16к. Луа, при редоктировании макросом больших файлов жрёт ресурсы. Колорер бывает необоснованно долго раскрашивает, при этом ресурсы кушает.
Использую airbrush, он хоть и кеширует себя в память, в первый раз долго, хато работает очень шустро.
Приходится таскать 2-е сборки фара, одна шустрая, другая имеет удобные плагины.
Редактор очень тормозит при загруженом 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
I know nothing except the fact of my ignorance. (с) Socrates