far.Timer: задержка и накопление событий

Здесь обсуждается всё, что касается макросов.
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

Latest post of the previous page:

zg wrote: Fri 17 Jan, 2025 04:02 в отличии от вас, телепатией не обладаю,
Зачем же телепатия, это лишь мой способ выразить мысль образно.
Можно вместо этого ограничиться бесстрастным анализом этого текста. Например, поставив вопрос: в какой степени автор уверен, что проблема действительно связана с сетью. И первое приближение даёт у меня <50%.
zg wrote: Fri 17 Jan, 2025 04:02 не вижу тут даже намёка на субъективность:
Вы предпочли бы чтобы я везде вставлял "ИМХО"?
zg wrote: Fri 17 Jan, 2025 04:02где я такое писал?
Снова моё образное саммари, извините. Значит на самом деле у вас другое мнение? Пожалуйста поправьте меня тогда.
zg wrote: Fri 17 Jan, 2025 04:02 вы пытаетесь чинить то, что не сломано, якобы заботясь об эффективности.
В общем и целом у таймера заметных проблем с эффективностью нет. А заботит меня то, что его реализация оставляет возможность крайних случаев, совершенно неочевидных из упомянутого вами Примечания 1.
И проявления этих крайних случаев будут опять же неочевидные, что делает их диагностику затруднительной.
Именно это меня занимает, а вовсе не средняя производительность.
zg wrote: Fri 17 Jan, 2025 04:02 вполне может оказаться, что в конкретной ситуации частное решение может оказаться гораздо эффективней вашего общего
Нельзя ли проиллюстрировать каким-нибудь, пусть и условным, примером? Потому что пока что я совсем не понял вашу мысль.
zg wrote: Fri 17 Jan, 2025 04:02 у меня два раза. и оба раза во время работы созданного тем же скриптом диалога. т.е. ваш фикс лучше точно не сделает. 0%.
Тут важно другое: станет ли вашим кейсам хуже от моего фикса? Нельзя ли конкретный пример, вдруг мы о разном говорим.
https://t.me/FarManager — Telegram чат
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

John Doe wrote: Fri 17 Jan, 2025 11:59 И проявления этих крайних случаев будут опять же неочевидные, что делает их диагностику затруднительной.
Именно это меня занимает, а вовсе не средняя производительность.
В настоящий момент Примечание 1 никак не противоречит наличному поведению, это правда, но несколько лукавая.
1. handler can be called only when the plugin returns control
to Far. Thus the real interval between handler calls is not
exact and can significantly differ from the specified value.
Исчерпывающим было бы другое изложение:
  • Реальный интервал между вызовами не гарантирован и в отдельных случаях может быть значительно больше, т.к. ... [кратко причина]
  • В связи с особенностями реализации таймера, вызовы обработчика ставятся в очередь безусловно и независимо от того, успевают ли они выполняться. А значит, в случаях когда ACTL_SYNCHRO будет фактически получать управление реже заданного в таймере интервала, то все пропущенные вызовы будут в очереди накапливаться, а затем выполняться разом, невзирая на значение интервала, т.е. вполне вероятно с около-0 интервалом.
    Следовательно, если ваш код чувствителен к этому, то необходимо использовать обёртку [код который привёл Shmuel]
Нигде в документации фара не описываются случаи, из-за которых ACTL_SYNCHRO может задерживаться, а значит строго говоря описанное выше поведение недетерминировано.
Предлагаемое мной усовершенствование направлено на повышение детерминированности. В результате второй пункт примечания будет не нужен.
Last edited by John Doe on Fri 17 Jan, 2025 15:56, edited 1 time in total.
https://t.me/FarManager — Telegram чат
User avatar
zg
zero-gravity
Posts: 6207
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 206 times
Contact:

Таймер и сборка мусора

Post by zg »

John Doe wrote: Fri 17 Jan, 2025 11:59Например, поставив вопрос: в какой степени автор уверен, что проблема действительно связана с сетью. И первое приближение даёт у меня <50%.
так хоть меньше процента. это всё равно больше, чем вероятность того, что виноват сам по себе ClickToDrive.lua.
John Doe wrote: Fri 17 Jan, 2025 11:59Вы предпочли бы чтобы я везде вставлял "ИМХО"?
в заявлениях такой категоричности — да.
John Doe wrote: Fri 17 Jan, 2025 11:59Снова моё образное саммари, извините. Значит на самом деле у вас другое мнение? Пожалуйста поправьте меня тогда.
  1. luafar api — очень сильный компромисс между свободой и безопасностью. с максимальным перекосом в сторону свободы. по большому счёту — это тонкая прокладка между lua и farapi, которое в свою очередь исторически отдаёт много внутренностей фар наружу. некоторые моменты luafar сглаживает в силу особенностей lua, но всё равно есть очень много способов только уронить фар с помощью апи, не говоря уже про менее критичные последствия типа потери производительности. это всё можно закостылить, но лично моя позиция, что ограничивая что-то плохое, мы убираем и что-то хорошее. например в рамках потенциальным "что-то может пойти не так" необходимо запретить любое изменение чужих диалогов. и для этого оснований гораздо больше, чем для ваших изменений таймера. можете провести опрос, чтобы узнать, сколько скриптописателей на это согласятся.
  2. мой опыт разработки фара показывает, что любые добавления, расширения, сужения, удаления какого-либо апи функционала без реально полезного примера — часто (по моим ощущениям всегда, но подозреваю, что хорошие примеры я забыл) вредны. например автор предложения что-то просит для своих целей, не озвучивает их, предлагая готовое описание, но оказывается, что для его целей можно сделать лучше и с более широким применением. или моё любимое: предложения, основанные на воображаемом внутреннем устройстве фара опять же без подробностей. поэтому: если нет полезного практического примера — смысла дальше двигаться нет.
конкретно про таймер:
  1. да, потенциально возможны тормоза, особенно на маленьких интервалах и тяжёлых обработчиках. но тяжёлые обработчики на малых интервалах — это в принципе плохо и в любом случае стоит подумать об изменении алгоритма. в остальных случаях последствия минимальны.
  2. судя по вашим рассуждения таймеры на низком уровне вы не отлаживали. а я вот отлаживал, недавно, по вашему багрепорту, сделанному без соблюдения правил. было и так сложно, а вы предлагаете всё ещё усложнить.
John Doe wrote: Fri 17 Jan, 2025 11:59что делает их диагностику затруднительной.
диагностику затруднительной делает несоблюдение правил по сообщению баг репортов. в том числе и вами.
John Doe wrote: Fri 17 Jan, 2025 11:59Тут важно другое: станет ли вашим кейсам хуже от моего фикса? Нельзя ли конкретный пример, вдруг мы о разном говорим.
первый пример: picture.lua, второй: в потоке совершается работа, таймер обновляет прогресс на открытом диалоге.
John Doe wrote: Fri 17 Jan, 2025 12:19а значит строго говоря описанное выше поведение недетерминировано.
действительно. наверное, стоит подумать об удалении этого кошмарного сна перфекциониста с тела святого фара.
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

zg wrote: Fri 17 Jan, 2025 21:13 а вы предлагаете всё ещё усложнить.
Сейчас в таймере есть куча свойств и методов, и я понимаю что всё непросто.
Но никак не ожидал что всё усложнит именно вот моё предложение: по сути ещё одно значение, обращение к которому надо будет синхронизировать между потоками.
Но со стороны реализации вам безусловно виднее.

Я тут выступаю со стороны пользователя API, и стремлюсь к упрощению: в частности можно будет не дёргать .Еnabled явно (как в сабжевом скрипте), и не заботиться о случаях накопления очереди пропущенных вызовов.
zg wrote: Fri 17 Jan, 2025 21:13 первый пример: picture.lua, второй: в потоке совершается работа, таймер обновляет прогресс на открытом диалоге.
Вы не ответили на вопрос повредит ли как-то предлагаемое изменение вашим кейсам.
https://t.me/FarManager — Telegram чат
User avatar
buniak_a_h
Posts: 4559
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 242 times
Been thanked: 674 times
Contact:

Таймер и сборка мусора

Post by buniak_a_h »

Я, кажется понял причину постепенного замедления работы компа, при том что проявлялось только у меня.
Натолкнуло меня на мысль это сообщение.
Т.к. я отлаживал скрипт, то я регулярно делал перезагрузку макросов. А получается, что при перезагрузке (а) имеющийся аймер продолжает работать, и (б) создаётся новый. За день перезагружу макросы раз 50 - вот вам и 50 одновременно работающих таймеров.
Да, какая-то тут засада…
User avatar
zg
zero-gravity
Posts: 6207
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 206 times
Contact:

Таймер и сборка мусора

Post by zg »

John Doe wrote: Sun 19 Jan, 2025 14:21Я тут выступаю со стороны пользователя API, и стремлюсь к упрощению: в частности можно будет не дёргать .Еnabled явно (как в сабжевом скрипте), и не заботиться о случаях накопления очереди пропущенных вызовов.
тогда можно и интервал выкидывать, с вашими предложениями в нём особо смысла нет.
John Doe wrote: Sun 19 Jan, 2025 14:21Вы не ответили на вопрос повредит ли как-то предлагаемое изменение вашим кейсам.
не очень понимаю, зачем я должен тратить на это время.
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

zg wrote: Mon 20 Jan, 2025 22:17 тогда можно и интервал выкидывать
Зачем это
zg wrote: Mon 20 Jan, 2025 22:17 не очень понимаю, зачем я должен тратить на это время.
Был уверен, что мы с вами тут тратим время абсолютно добровольно.
И если бы вы пролили свет на этот вопрос, то это было бы первым возражением по существу (ИМХО).

То что я вижу в теме до сих, можно свести к двум пунктам
  • Нафиг надо, это всё равно копейки сэкономит.
  • Реализация может осложнить отладку таймера на низком уровне.
Со вторым мне спорить сложно, первое уже обсудили (но я даже не к экономии стремлюсь).

Итак по существу мне хотелось бы избавиться от такого Примечания:
John Doe wrote: Fri 17 Jan, 2025 12:19 В связи с особенностями реализации таймера, вызовы обработчика ставятся в очередь безусловно и независимо от того, успевают ли они выполняться. А значит, в случаях когда ACTL_SYNCHRO будет фактически получать управление реже заданного в таймере интервала, то все пропущенные вызовы будут в очереди накапливаться, а затем выполняться разом, невзирая на значение интервала, т.е. вполне вероятно с около-0 интервалом.
Вы очевидно напротив, извлекаете какую-то пользу из описанного поведения, и видимо считаете его изменение разрушит ваш юзкейс.
Возможно если бы вы показали сразу, какова ваша специфика, то это сохранило бы нам время, и для этой продолжительной дискуссии не возникло бы даже повода.

Разумеется я принимаю ваше право распоряжаться собственным временем, и не считаю что вы должны отвечать на мой вопрос, или иным образом продолжать эту беседу.
https://t.me/FarManager — Telegram чат
User avatar
zg
zero-gravity
Posts: 6207
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 206 times
Contact:

Таймер и сборка мусора

Post by zg »

John Doe wrote: Tue 21 Jan, 2025 12:32Зачем это
что именно? предложение выкинуть интервал? если вы думаете, что я шучу, то нет, я вполне серьёзно. в текущей реализации можно взять таймер с интервалом m, выполнить p раз и замерить время ti. проделать это много раз, и тогда матожидание от ti/p будет стремиться к m, при маленькой дисперсии. если же взять реализацию, предлагаемую вами, то такого уже в общем случае не будет. и что тогда такое задаваемый интервал? вы, не знаю осознанно или нет, пытаетесь превратить таймер в очень продвинутый аналог DN_ENTERIDLE.
John Doe wrote: Tue 21 Jan, 2025 12:32И если бы вы пролили свет на этот вопрос, то это было бы первым возражением по существу (ИМХО).
возражением против чего? против 99% случаев, когда текущая реализация тормозит, а предложенная вами — нет? видите ли, я в голову к вам залезть не могу. и вот в момент, когда вы достанете из своей головы эти 99% случаев, расскажете о них, и хотя бы часть из них окажется полезной и не реализуемой по другому, то я с вами продолжу общаться.
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

zg wrote: Wed 22 Jan, 2025 02:42 [...]и тогда матожидание от ti/p будет стремиться к m, при маленькой дисперсии.
Вы теоретизируете, или именно эту особенность эксплуатируют два упомянутых вами случая?
zg wrote: Wed 22 Jan, 2025 02:42 и что тогда такое задаваемый интервал?
Ровно то, что сказано (или будет сказано) в документации.
zg wrote: Wed 22 Jan, 2025 02:42 вы, не знаю осознанно или нет, пытаетесь превратить таймер в очень продвинутый аналог DN_ENTERIDLE.
В том смысле, что DN_ENTERIDLE не добавлял "холостые" события, ради того чтобы подогнать некую "среднюю" их частоту к нарисованной вами выше математической модели - да. Но интервал оставьте.
zg wrote: Wed 22 Jan, 2025 02:42 [...]то я с вами продолжу общаться.
Вы намеренно вот так свысока? Полагаете, это стимулирует обсуждение по существу?
zg wrote: Wed 22 Jan, 2025 02:42 против 99% случаев, когда текущая реализация тормозит, а предложенная вами — нет?
В этой теме я многократно объяснял, что заботит меня не торможение.
(Тут вы на моём месте вероятно написали бы, что продолжите общаться, когда собеседник научится читать)

Я же повторюсь: возражение против моего предложения по улучшению функционирования АПИ (обоснованного мною выше), в виде описания реального юзкейса, который бы пострадал (т.е. стал бы сложнее реализуем) при таковом изменении.
https://t.me/FarManager — Telegram чат
User avatar
buniak_a_h
Posts: 4559
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 242 times
Been thanked: 674 times
Contact:

Таймер и сборка мусора

Post by buniak_a_h »

zg wrote: Wed 22 Jan, 2025 02:42 превратить таймер в очень продвинутый аналог DN_ENTERIDLE.
Я так и не понял, почему это событие упразднили. Было ну ооочень удобно!
User avatar
zg
zero-gravity
Posts: 6207
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 206 times
Contact:

Таймер и сборка мусора

Post by zg »

buniak_a_h wrote: Thu 23 Jan, 2025 12:34Я так и не понял, почему это событие упразднили. Было ну ооочень удобно!
потому что нормально не работало. любая внешняя программа, спамящая в текущую консоль «пустыми» событиями отключала DN_ENTERIDLE. исторически первым обнаруженным был explorer.exe, спамящий нулевыми перемещениями мыши при анимации иконки в трее. очень неожиданно, искали долго. были ещё какие-то примеры такого же, уже не помню.
User avatar
buniak_a_h
Posts: 4559
Joined: Sat 20 Apr, 2013 00:17
Location: Санкт-Петробад
Has thanked: 242 times
Been thanked: 674 times
Contact:

Таймер и сборка мусора

Post by buniak_a_h »

zg, спасибо за понятный и развёрнутый ответ.
Может, расскажете ещё, почему убрали группу событий PanelEvent? Так было бы здорово вешать "дорисовку" панелей на это, а не на таймер и не на консольное событие.
User avatar
zg
zero-gravity
Posts: 6207
Joined: Tue 15 Mar, 2005 17:36
Location: riga
Been thanked: 206 times
Contact:

Таймер и сборка мусора

Post by zg »

buniak_a_h wrote: Thu 23 Jan, 2025 17:07Может, расскажете ещё, почему убрали группу событий PanelEvent?
не было такой группы. подозреваю, что уши растут из ProcessPanelEvent, но это исключительно для собственных панелей. в луамакро этот функционал есть в панельных модулях.
User avatar
John Doe
Бюрократ
Posts: 14580
Joined: Wed 27 Apr, 2005 20:42
Location: github.com/FarManagerLegacy
Has thanked: 92 times
Been thanked: 514 times
Contact:

Таймер и сборка мусора

Post by John Doe »

buniak_a_h wrote: Thu 23 Jan, 2025 17:07 почему убрали группу событий PanelEvent?
Такая группа была бы возможной при реализации https://bugs.farmanager.com/view.php?id=2826.
Комментарий zg по этому поводу можно увидеть по ссылке http://forum.farmanager.com/viewtopic.p ... 24#p124024
Last edited by HaRT on Thu 23 Jan, 2025 19:03, edited 1 time in total.
Reason: Исправлен источник цитаты
https://t.me/FarManager — Telegram чат
Post Reply

Return to “Обсуждение макросов”