Editor strings representation

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

Editor strings representation

Post by DrKnS » Wed 22 Feb, 2017 22:19

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

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

Shmuel
Posts: 5202
Joined: Thu 23 Mar, 2006 21:36
Location: Israel
Has thanked: 16 times
Been thanked: 148 times

Editor strings representation

Post by Shmuel » Wed 22 Feb, 2017 23:08

Меня и нынешняя ситуация устраивает. Хотя если ничего не сломается, то всё равно.
ECTL_GETSTRING, который сейчас просто отдаёт указатель, замедлится в разы, но вряд ли это будет сильно заметно в общей картине.

2useven10
Posts: 3010
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 2 times
Been thanked: 82 times

Editor strings representation

Post by 2useven10 » Wed 22 Feb, 2017 23:23

А стоит ли овчинка? Чтобы ничего не сломалось - это фантастика.
И если всё-таки переделывать, я бы просто хранил строку в ACP, если можно,
или как сейчас, если в ACP не влезет, чтобы не возиться постоянно с переменно длинным UTF-8.

User avatar
HaRT
Moderator
Posts: 8075
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 67 times
Been thanked: 100 times

Editor strings representation

Post by HaRT » Wed 22 Feb, 2017 23:35

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: 8075
Joined: Tue 30 Aug, 2005 17:21
Location: Санкт-Петербург
Has thanked: 67 times
Been thanked: 100 times

Editor strings representation

Post by HaRT » Wed 22 Feb, 2017 23:37

DrKnS wrote: на ascii-данных (коих большинство) экономия в два раза
А теперь представим себе какой-нибудь дамп большой БД на каком-нибудь азиатском языке — вместо выигрыша получим ощутимый проигрыш.
Фар есть инструмент, а не нянька. © 2009 DrKnS

User avatar
DrKnS
Posts: 4618
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 4 times
Been thanked: 121 times
Contact:

Editor strings representation

Post by DrKnS » Wed 22 Feb, 2017 23:46

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

User avatar
ctapmex
Posts: 990
Joined: Fri 11 Apr, 2008 07:53
Been thanked: 2 times
Contact:

Editor strings representation

Post by ctapmex » Thu 23 Feb, 2017 10:08

памяти то конечно сэкономит. проигрыш в скорости будет не значительным. можно накидать небольшой бенчмарк сколько займет времени преобразование файла из одной кодировки в другую.
есть такое движение http://utf8everywhere.org/

User avatar
zg
zero-gravity
Posts: 5263
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 43 times
Contact:

Editor strings representation

Post by zg » Thu 23 Feb, 2017 11:12

пробовать можно уже сейчас. в макросах обратное преобразование, не думаю, что разница в скорости utf8->utf16 и utf16->utf8 значительная. так вот можно ту же подсветку сравнить. на длинных строках. с табами.
я против. память нужно один раз докупить, тормоза - всё время.

User avatar
zg
zero-gravity
Posts: 5263
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 43 times
Contact:

Editor strings representation

Post by zg » Thu 23 Feb, 2017 15:01

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

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: 28
Joined: Thu 20 Nov, 2014 20:10
Location: Санкт-Петербург
Has thanked: 5 times
Been thanked: 1 time
Contact:

Editor strings representation

Post by Freeman » Sat 25 Feb, 2017 11:13

DrKnS wrote:Я по-прежнему являюсь сторонником подхода "купите больше памяти", но мало ли, может у кого-то опыт положительный есть.
По логике, дампы связаны с серверами, а для серверов и/или рабочих мест для их обслуживания сам бог велел докупить памяти.
zg wrote:память нужно один раз докупить, тормоза - всё время.
Верно!
Разработчик языка программирования Кантор

User avatar
cmd.exe
Posts: 333
Joined: Fri 16 Apr, 2010 18:26
Location: Нижний Новгород
Has thanked: 170 times
Been thanked: 5 times
Contact:

Editor strings representation

Post by cmd.exe » Sun 26 Feb, 2017 18:51

Проблем в сравнении с переходом неувидел. Дальше оффтопик.
Редактор очень тормозит при загруженом 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”