slow colorer background parsing

[lieff]

При редактировании больших файлов вроде https://github.com/vurtun/nuklear/blob/master/nuklear.h , если сразу спозиционироваться в конец, можно ждать парсинга colorer вечно.
Предлагаю такое решение: lieff@b712007
Это быстро увеличивает объем парсинга до 10000 строк\итерацию. Время ожидания на nuklear.h сокращается до ~5 секунд. Если во время не завершенного процесса сдвинуть курсор, можно заметить залипание, но оно не большое.

[elfmz]

хм а тормозить не начинает ниче? я конечно понимаю что видимо этот код писался гденить в районе 2010го.. но требовать для работы минимум i5 не хотелось бы..
погоняю дома фикс на виртуалке там будет видно.. Вообще правильно было бы наверное этот time делать адаптивным, засекая иногда время работы clock'ом и уменьшая/увеличивая time, но это наверное слишком сложно..

[lieff]

Да, я тоже об этом подумал, правильно будет точно загрузить одно ядро. Иначе слишком мощный проц будет простаивать, увеличивая время ожидания, а слишком медленный приведет к большим залипам при нажатии клавиш.
Просто тут "idle" таск реализован в основном цикле, был бы отдельный тред, проблемы бы небыло.
Пока как воркароунд можно подобрать число более подходящее, на винде итерации видимо случались гораздо чаще, вот 100 строк\итерация теперь и не подходит.

[elfmz]

хмхмхм.. это уже интереснее, я думал оно и в винде так же было, а хочется чтоб было лучше)
значит нуна фиксить какой то баг..
Навскидку: в colorer' и в самом FAR местами юзается clock(), и судя по коду считается авторы полагались на то что он возвращает всегда миллисекунды. А он возвращает 1/CLOCKS_PER_SEC, причем в студии CLOCKS_PER_SEC 1000, а в линуксе - обычно 1000000
Так что предлагаю вернуть как былО, написать некую
clock_msec(){ return clock() / (CLOCKS_PER_SEC / 1000); }
поменять все clock() на clock_msec() и посмотреть что будет..

[lieff]

Ну там 100\итерация это максиум, а это мало как что ни рассчитывай. Sleep то там нет, а частота итераций снизилась, это основная проблема со старым лимитом.

[elfmz]

полагаю у этого кода уши растут из генерируемого far'ом KEY_IDLE, а в фаре слипов полно,
кстати в оригинальном фаре слипы были в основном 1мсек, я их поменял на 10 мсек :)
НО это не должно было вызвать изменений т.к. в винде разрешение системного таймера по дефолту 10..15мсек и меньше 10мсек слипы в винде не спят.

[lieff]

Да, меньше 10мс не получится, если только там нет алгоритма компенсации вроде 1 раз 10мс, второй раз 0мс -> 5ms. В любом случае так мало спать и часто переключать контексты вредно, то то виндовый far2 под wine жрет проц ощутимо.
Думаю лимит 100 в любом случае прдется поднять, но возможно не так сильно, если разобраться с часторой итераций. Скажем более 60 итераций\сек не нужно для нормальной интерактивности и чтобы не грузить проц. Значит старый лимит даст 6000строк\с, что мало.

[elfmz]

ну да, но по любому гдето тут еще мой баг зарыт, раз появилась такая разница с частотой idle ивентов

[elfmz]

Вощем... Проверил у себя - действительно, ProcessEditorInputW с KEY_IDLE под виндой фаром дергается на глазок в 10 раз чаще чем в линуксовом порте. Стал копать.. иии. Вкратце - это подводный граблебаг FAR'а:)
Подробнее - дело действительно в перекоцанных мною Sleep(1) на Sleep(10). Если вернуть Sleep(1) - то и под линуксом приходит все ок. Стало интересно, как же оно в винде работало, т.к. time slice в винде точно >=10msec, а значит спать в винде должно тоже по 10 мс, даже когда просишь 1.
Но по факту спит оно таки по одной мс. "Хм", подумал я, и закрыл все прилаги, кроме подопытного фара и еще кое чего по-мелочи. И тада - в виндовом фаре KEY_IDLE тоже стал приходить так же редко как в линуксовом.
Разгадка - есть такая ф-я - timeBeginPeriod. Вызвав ее например timeBeginPeriod(1) можно временно уменшить time slice шедулера до 1мсек. Временно - это значит до того как вызовешь timeEndPeriod(1) или как процесс выйдет и система сама все отменит, т.к. меньшее разрешение шедулера ухудшает его эффективность. И поэтому мсдн там в ремарках рекомендует минимизировать использование этой штуки.
Но поскольку рукожопость в мире процветает, то в зоопарке запущенных программ найдется ктото кому захочется мерять время с разрешением в 1мсек постоянно, потому в FAR'е, который запущен в среде зоопарка KEY_IDLE приходят в 10 раз чаще чем в FAR'е, запущенном на чистой системе.
А я между прочим и раньше замечал что колорер иногда странно тупит с перерисовкой, но не придавал этому значения. Теперь все встало на свои места.

[elfmz]

а пулреквест делайте да как ща.. 10 мсек на 1мсек я заменять не буду - некрасиво это спать по 1й мсек.. Тем более что под виндой у фара (причем и у 3го) тут тоже полная неоднозначность.. А потом если будет время и желание - можно будет сделать адаптивную логику

[lieff]

Чтобы сделать пул реквест, мне надо снова отменить подключение netbox и кореженье WinPort, гитхаб как оказалось не поддерживает cherry-pick) я собственно потому и сделал issue со ссылкой на коммит, я не сразу пул реквест.

[elfmz]

ну я думаю это не к спеху..
кстати насчет кореженья - я думаю я таки порасставляю потом по нетбоксу макрос WINPORT, т.к. уж больно велик риск конфликта символов - больно вкусные названия у виндовых функций, если в процесс загрузится какая нить библиотека которая экпортирует чтонить с таким же именем - будут крайне неприятные проблемы..
мм.. или чтоли тупо передефайнить все эти функции для нетбокса..

[lieff]

По идее -Wl,--version-script=exports.def сделает так что из so гарантированно будут торчать только символы из .def, даже без -fvisibility=hidden
Файл следующего вида:

     {
    global:
      JNI_*;
      Java_*;
      local: *;
    };

Из so тогда будут торчать только JNI_* и Java_*

[elfmz]

не, я про то что если в FAR будет загружена .so-шка не нами скомпиленная.. а так, из системы чтото. И если она будет экспортировать, скажем, CloseHandle и будет еще какаято другая левая .so, которая будет линковаться на этот CloseHandle. Так вот, загрузившись в far2l, который будет так же экспортировать CloseHandle - та вторая будет юзать CloseHandle из far2l. Так уж в линуксе лоадер работает, это в винде (и OSX с ее mach-o) точно указано из какой длл должен прилинковаться каждый конкретный символ..

[lieff]

А netbox не будет линковаться с CloseHandle, он у него будет внутри статически слинкован и наружу не торчать. И far2l не нужно CloseHandle экспортировать. Так что пока экземпляры WinPort полностью независимы и не экспортируются все должно быть ок. Главное не передать handle из far2l в плагин и не сделать на нем CloseHandle() в плагине (между копиями WinPort).

[elfmz]

Так вот это вот неправильно. Во-первых каждому бинарнику таскать с собой общий код - не комильфо. Во-вторых проблемы не только с хэндлами. Первое на чем вылезут грабли - консольные API не будут работать в плагинах (а они их юзают частенько напрямую), потому что инстанс консоли только один - у фара. Плагин может конечно тогда инициализировать свою консоль - тогда вылезет еще одно окошко, с его личной консолью :)

[lieff]

Ну да, потому netbox еще далеко не готов, надо переводить часть winapi на те функции что far2l передает в таблице функций, другую часть на нативный linux, и оставшееся на то, чем можно пользоваться из плагинов, проблем с путаньем линковки между so вроде на данном этапе нет.

[elfmz]

Вощем мы посовещались и я решил :)
Немного громозко, зато надежно. И не нужно переколбашивать ни netbox, ни WinPort.

[elfmz]

И по поводу сабжа - тоже вкомитил фикс почти как ваш только ограничение time 1000, а не 10000. Соображения такие - раз замедлилось в 10 раз, то и лимит нужно поднять примерно так же.

[elfmz]

возвращаясь к нетбоксу - попробовал собрать и обнаружил пару проблем, возможно вы не заметили: хедеры в PluginSDK были не очень совместимые с тем что в far2l + по мелочи - добавил копирование .lng И проверку чтоб не падало в одном месте) теперь оно у меня тоже собралось и даже меню появилось.. но при попытке добавить сервер упало(

[elfmz]

завел issue для "всего": #14
а эту закрою ибо зафикшено

[lieff]

Да, этот лимит тоже норм, на nuklear.h у меня 7 секунд.