[Вопрос] "Long callback execution detected (hang or performance issue)" и long_call_time [Архив] - Pro Pawn

Просмотр полной версии : [Вопрос] "Long callback execution detected (hang or performance issue)" и long_call_time

quinsaiz

18.01.2023, 01:21

[17-01-2023 23:13:26] [debug] Long callback execution detected (hang or performance issue)
[17-01-2023 23:13:26] [Info] [debug] AMX backtrace:
[17-01-2023 23:13:26] [Info] [debug] #0 00000710 in Iter_ScriptInit () at D:\Desktop\OpenMP\pawno\include\foreach.inc:740
[17-01-2023 23:13:26] [Info] [debug] #1 000003cc in public OnGameModeInit () at D:\Desktop\OpenMP\pawno\include\foreach.inc:660

Получаю данное сообщение в логах, во время использования crashdetect и ключем "-d3". К серверу со стороны клиента невозможно подключиться.

Инклуд foreach 2.2.3 от Ziggi, прикрепляю ниже.
Вопрос: это у меня не оптимизированый код, хотя в samp-server нету подобных ошибок, или под open.mp нужно и переписать foreach, или ждать версию crashdetect под open.mp?

[I]foreach.inc – pastebin (https://pastebin.com/UjvqdXEJ)

- - - Добавлено - - -

UPD: проблема в этой строчке, наверное в "LAST_VEHICLE_ID"

739: for (new vehicleid = 1; vehicleid != LAST_VEHICLE_ID; ++vehicleid) {

Shaolinka

18.01.2023, 02:25

long_call_time 0

В server.cfg

И к чему делать такой цикл, имея в арсенале foreach. Гораздо проще замутить перехват нативной CreateVehicle, добавляя ID созданного транспорта непосредственно в итератор, не изобретая таких вот велосипедов. Тем более, не до конца ясно значение LAST_VEHICLE_ID

quinsaiz

18.01.2023, 02:57

Во-первых, server.cfg нету, поскольку это open.mp, тут другой файл-конфиг.
Во-вторых, цикл этот в самом инклуде foreach, 739 строка, файл прикрепил; Значение переменной LAST_VEHICLE_ID в строке 694 того же инклуда, у себя я позже установил на 0
#if defined GetPlayerPoolSize
new
LAST_PLAYER_ID = 0,
LAST_VEHICLE_ID = 0,
LAST_ACTOR_ID = 0;
#else
#define LAST_PLAYER_ID MAX_PLAYERS
#define LAST_VEHICLE_ID MAX_VEHICLES
#define LAST_ACTOR_ID MAX_ACTORS
#endif, в оригинале оно равно LAST_VEHICLE_ID = GetVehiclePoolSize() + 1, но open.mp не позволяет использовать функции Get***PoolSize, подробней[кликабельно] (https://www.open.mp/docs/scripting/functions/GetVehiclePoolSize), то есть мне сам компилятор давал варнинги, за использование данных функций.

Nexius_Tailer

18.01.2023, 02:59

В форке от Ziggi используется Get(Player/Vehicle)PoolSize внутри условия в одном из циклов, которое ломается и уходит в бесконечный цикл, если PoolSize функции начинают возвращать что-то меньше нуля. В омп завезли некоторые неуместные вещи из fixes.inc, так что поведение PoolSize функций было как раз изменено на подобное (возвращают -1, когда нет никаких созданных игроков или машин на сервере). По этой причине советую использовать другой форк от Kar'a (ссылка (https://github.com/karimcambridge/samp-foreach)), где эти функции не используются вообще и такого риска уйти в зависон нет.

- - - Добавлено - - -

UPD: немного опередили, да. PoolSize функции для омп сервера ещё впридачу и помечены как deprecated, также по причине выше.

Во-первых, server.cfg нету, поскольку это open.mp, тут другой файл-конфиг.
Отлично есть, просто в режиме legacy (читай как полностью работает в данный момент для обратной совместимости на пару с .json конфигом)

quinsaiz

18.01.2023, 03:10

В форке от Ziggi используется Get(Player/Vehicle)PoolSize внутри условия в одном из циклов, которое ломается и уходит в бесконечный цикл, если PoolSize функции начинают возвращать что-то меньше нуля. В омп завезли некоторые неуместные вещи из fixes.inc, так что поведение PoolSize функций было как раз изменено на подобное (возвращают -1, когда нет никаких созданных игроков или машин на сервере). По этой причине советую использовать другой форк от Kar'a (ссылка (https://github.com/karimcambridge/samp-foreach)), где эти функции не используются вообще и такого риска уйти в зависон нет.

- - - Добавлено - - -

UPD: немного опередили, да. PoolSize функции для омп сервера ещё впридачу и помечены как deprecated, также по причине выше.

Отлично есть, просто в режиме legacy (читай как полностью работает в данный момент для обратной совместимости на пару с .json конфигом)

Сначало я использовал именно форк который Вы предоставили, но меня смутило предупреждение в логах
[Warning] Parameter count does not match specifier in `Script_Call`. callback: Iter_OnGameModeInit - fmat: - count: 3)
По config.json я не нашел был документации, плагины в режиме легаси подключил, а вот long_call_time 0 стал прописывать именно в config.json :sorry:, то есть можно создать server.cfg и прописывать там от старых плагинов параметры?

Nexius_Tailer

18.01.2023, 03:15

По config.json я не нашел был документации, плагины в режиме легаси подключил, а вот long_call_time 0 стал прописывать именно в config.json :sorry:, то есть можно создать server.cfg и прописывать там от старых плагинов параметры?
Да, пока что можно юзать server.cfg полноценно, если какие-то плагины вроде крашдетекта до сих пор читают именно server.cfg и не видят кастомные параметры заданные в config.json. Тем не менее, даже после любой возможной адаптации крашдетекта именно под омп сервер, "long_call_time" всё равно придётся отключать, т.к. ложных срабатываний у него больше, чем реальных обнаружений действительно медленных участков. Иными словами, реализовали недопиленную фичу и включили по умолчанию. От самп или омп сервера это там не зависит, чисто в крашдетекте проблема.

Сначало я использовал именно форк который Вы предоставили, но меня смутило предупреждение в логах
[Warning] Parameter count does not match specifier in `Script_Call`. callback: Iter_OnGameModeInit - fmat: - count: 3)
Хм, ну можно тогда попытаться закинуть доработки в один или второй форк, поправив эту или предыдущую проблему там и там. Просто авторы их вроде уже давно не обновляют и не факт, что проверят эти правки и примут в ближайшем будущем.

quinsaiz

18.01.2023, 03:18

Да, пока что можно юзать server.cfg полноценно, если какие-то плагины вроде крашдетекта до сих пор читают именно server.cfg и не видят кастомные параметры заданные в config.json. Тем не менее, даже после любой возможной адаптации крашдетекта именно под омп сервер, "long_call_time" всё равно придётся отключать, т.к. ложных срабатываний у него больше, чем реальных обнаружений действительно медленных участков. Иными словами, реализовали недопиленную фичу и включили по умолчанию. От самп или омп сервера это там не зависит, чисто в крашдетекте проблема.

А что делать с предупреждением? Ничего страшного? "long_call_time 0" по сути не помогло против подобного, сервер не стартует, мб стоит попробывать использовать старые версии crashdetect'a?

- - - Добавлено - - -

Да, пока что можно юзать server.cfg полноценно, если какие-то плагины вроде крашдетекта до сих пор читают именно server.cfg и не видят кастомные параметры заданные в config.json. Тем не менее, даже после любой возможной адаптации крашдетекта именно под омп сервер, "long_call_time" всё равно придётся отключать, т.к. ложных срабатываний у него больше, чем реальных обнаружений действительно медленных участков. Иными словами, реализовали недопиленную фичу и включили по умолчанию. От самп или омп сервера это там не зависит, чисто в крашдетекте проблема.

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

А если удалить итер Vehicle из Форка от Ziggi, и не использовать его? Сервер стартует после удаление функций PoolSize

Nexius_Tailer

18.01.2023, 03:24

А что делать с предупреждением? Ничего страшного? "long_call_time 0" по сути не помогло против подобного, сервер не стартует, мб стоит попробывать использовать старые версии crashdetect'a?
Если сервер не запускается, значит есть какие-то другие, гораздо более серьёзные проблемы. Просмотри логи по-подробнее. Насчёт крашдетекта, можно юзать чуть более старые версии (до появления этой диагностики), либо попробовать вот эти чуть доработанные версии, где была пара фиксов как раз относительно последнего: https://github.com/Y-Less/samp-plugin-crashdetect/releases (хотя я не уверен, что они всё ещё решают хоть какую-то значительную часть ложных срабатываний). В любом случае, "long_call_time 0" внутри server.cfg должно отключать эту функцию и на самп, и на омп сервере без каких-либо проблем.

- - - Добавлено - - -

А если удалить итер Vehicle из Форка от Ziggi, и не использовать его? Сервер стартует после удаление функций PoolSize
А, значит твой сервер как раз и уходит в зависон из-за форка foreach от ziggi. Да, можешь попробовать фиксануть там это самостоятельно (и заодно тогда предложить это изменение в его репозиторий), но проще наверное заюзать форк от Kar.

quinsaiz

18.01.2023, 03:34

Если сервер не запускается, значит есть какие-то другие, гораздо более серьёзные проблемы. Просмотри логи по-подробнее. Насчёт крашдетекта, можно юзать чуть более старые версии (до появления этой диагностики), либо попробовать вот эти чуть доработанные версии, где была пара фиксов как раз относительно последнего: https://github.com/Y-Less/samp-plugin-crashdetect/releases (хотя я не уверен, что они всё ещё решают хоть какую-то значительную часть ложных срабатываний). В любом случае, "long_call_time 0" внутри server.cfg должно отключать эту функцию и на самп, и на омп сервере без каких-либо проблем.

Сервер запустился с crashdetect`oм от Y_Less и foreach от Kar`a. Варнинг остался, наверное просто нужно будет переписать OnGameModeInit в форк от Kar`a, взять код из варианта от Ziggi

Nexius_Tailer

18.01.2023, 03:37

Сервер запустился с crashdetect`oм от Y_Less и foreach от Kar`a. Варнинг остался, наверное просто нужно будет переписать OnGameModeInit в форк от Kar`a, взять код из варианта от Ziggi
Насколько я помню, версии от Kar и от Ziggi довольно сильно разнятся. Если тебе нужны какие-то встроенные итераторы из версии Ziggi (их там вроде бы больше из коробки было), то это вообще не проблема просто добавить их вручную)

punkochel

19.01.2023, 14:46

Nexius_Tailer

19.01.2023, 18:51

Предложу свой форк foreach от ziggi: https://github.com/punkochel/foreach
Тут просто добавлена совместимость с open.mp в силу изменений GetPool*Size, при инициализации инклуда.
Можно было бы заодно тогда и fixes.inc учитывать, т.к. он их поведение также менял.

punkochel

19.01.2023, 19:28

Да, спасибо. Добавлю.

DeimoS

19.01.2023, 21:09

punkochel

19.01.2023, 21:19

Как я понимаю, вопрос решён?

Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.

Nexius же считает, что плагин должен сам волшебным образом подстраиваться под любой скрипт (видимо, в плагин нужно ИИ вшивать, который отдельно бы, после каждой компиляции, часами изучал исходники и определял то, сколько они должны, в идеале, обрабатываться), учитывая ещё и какие-то внешние нагрузки. Правда, сколько я ни пытался от него добиться ответа, он так и не уточнил, какую в этом случае должен давать полезную информацию плагин. Ибо я не вижу ничего полезного в замерах того, какую нагрузку выдаёт мод вместе с другими процессами, запущенными в системе. Эту задачу прекрасно выполняет какой-нибудь "Процессор задач" из Windows. Но непонятому гению виднее :pardon:

Я согласен с Nexius. Дело в том что определять long_call_time для pawn-скриптов не самое лучшее занятие. pawn.cc это самый примитивный компилятор, который мало что умеет оптимизировать и ни о каких inline-функциях тут и речи не идет.
Если мы в GameModeInit вызовем функцию, которая создает объекты на сервере, то мы в любом случае получим сообщение long_call_time.
Если-же мы пишем мод в одном файле, дублируя многие участки кода и т.д. то наверное мы могли бы добиться чуть большей производительности. Но если мы пишем "модульный" мод, в котором системы раскиданы по различным директориям и использование модулей осуществляется через функции, то long_call_time будет выдавать нам сообщение довольно часто, а об использовании рекурсии можно вообще забыть, если бояться подобных сообщений.

UPD:
Да, на beta стадии можно ради спортивного интереса посмотреть какие функции нагружают систему сильнее, но как таковой практической пользы эта функция не несет.

DeimoS

19.01.2023, 21:38

Я согласен с Nexius. Дело в том что определять long_call_time для pawn-скриптов не самое лучшее занятие. pawn.cc это самый примитивный компилятор, который мало что умеет оптимизировать и ни о каких inline-функциях тут и речи не идет.
Если мы в GameModeInit вызовем функцию, которая создает объекты на сервере, то мы в любом случае получим сообщение long_call_time.
Если-же мы пишем мод в одном файле, дублируя многие участки кода и т.д. то наверное мы могли бы добиться чуть большей производительности. Но если мы пишем "модульный" мод, в котором системы раскиданы по различным директориям и использование модулей осуществляется через функции, то long_call_time будет выдавать нам сообщение довольно часто, а об использовании рекурсии можно вообще забыть, если бояться подобных сообщений.

Эмм, так подбери актуальное значение для long_call_time, если уверен, что текущая конфигурация твоего скрипта работает достаточно эффективно для тебя, и не будет никаких "ложных" вызовов.

Ты, видимо, тоже не особо понимаешь как работает "long_call_time", судя по написанному. Ибо всё, что она делает - замеряет то, как долго обрабатывается код в коллбэке, после сверяет результат со значением из "long_call_time" и если первое превышает второе - выдаёт предупреждение. Соответственно, всё, что тебе нужно - это замерить то, сколько у тебя обрабатывается тот же OnGameModeInit, а после вызвать в нём же "SetCrashDetectLongCallTime" и указать в неё замеренное ранее время с некоторым запасом. Всё, "ложные" срабатывания волшебным образом прекратились.
А можешь поступить ещё более невероятным образом: отключить данный функционал через вызов "DisableCrashDetectLongCall" в OnGameModeInit для всего мода, а после включать его (EnableCrashDetectLongCall/SetCrashDetectLongCallTime) только для тех функций, время обработки которых тебе хотелось бы контролировать.
В общем, как я уже как-то говорил Nexius - все ваши "ложные" срабатывания сугубо от того, что вы не понимаете для чего нужен данный функционал и как именно его использовать. Хотя вообще профилировщик - это достаточно тривиальная штука. И на тот же плагин "profiler (https://github.com/Zeex/samp-plugin-profiler)" почему-то никто не кидается с криками: "Он сообщает мне о том, что мой код работает медленно!". А когда тот же самый профилировщик вставили в crashdetect (плагин, который существует для дебага), некоторые вдруг не опознали в профилировщике профилировщика (да и вообще, судя даже по твоему сообщению, не особо поняли с чем имеют дело и каким оно должно, по их мнению, быть на самом деле) и начали говорить про какой-то кривой функционал.

Ну и сразу говорю, что какого-то срача тут не будет (а если кто-то захочет начать - он быстро исчезнет). Расписываю всё это сугубо для тех, кто не понимает зачем нужен "long_call_time". Если же у кого-то всё ещё осталось желание оспорить сказанное мной - вбивайте в гугл "профилирование в программировании" и спорьте с ним.

UPD:
Да, на beta стадии можно ради спортивного интереса посмотреть какие функции нагружают систему сильнее, но как таковой практической пользы эта функция не несет.

Эмм, весь плагин "crashdetect" создан для отладки кода. Пускать вместе с ним сервер в прод = замедлять и без того не шустрый Pawn.
А касаемо "спортивного интереса": ну когда ты будешь писать код либо на заказ, либо с целью создать что-то серьёзное, а не просто скриптики для себя в свободное время - тогда и поймёшь, зачем может понадобиться контролировать те или иные участки кода на предмет того, что они не обрабатываются дольше определённого времени (например, проверять то, что секундные таймеры срабатывают именно за секунду? Или что код в OnPlayerUpdate не вызывает серьёзных задержек?). И тут ты уже вспомнишь о "long_call_time", поблагодарив Y_Less за него, ибо тебе не придётся изобретать собственный велосипед или же пытаться вычленить нужную информацию из отчёта плагина "profiler", а будет готовое решение, которое легко интегрируется и управляется. Ну либо, потенциально, в проде игроки поймают лаги/диссинхроны и тебе придётся впопыхах страдать над оптимизацией :pardon:

punkochel

19.01.2023, 22:04

Не понимаю почему ты так к этому прицепился. Но лично для меня, да и думаю что многих других тоже, эта функция скорее помеха чем фича, потому-то необходимо тратить время на её отключение, так как она включена по умолчанию. А для замера скорости тех или иных реализаций для меня прекрасно подходит этот Профайлер (https://pro-pawn.ru/showthread.php?12585). Ну а замерять целые куски кода, которые определяются совокупностью тех или иных реализаций, как по мне это не то чем нужно заниматься.

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

Подведу итог:
В наше время программируя на pawn и при этом цепляться за каждый упущенный такт процессора это весьма сомнительная работа. Сейчас даже микроконтроллеры в будильнике мощнее чем в инженерных калькуляторах 2000-х годов.
Подобное можно сравнить вот с этим:

https://www.youtube.com/watch?v=j4xNIeYNG7A

Nexius_Tailer

20.01.2023, 02:57

Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.
Той "глупости", которую и сам автор этого нововведения признаёт как дефект? Из предыдущего диалога это ты отказываешься понимать очевидную вещь: то, что даёт ложных больше, чем не ложных - изначально плохой инструмент. То, что не указывает на реальную причину, но лишь на следствие - изначально плохой инструмент. Конкретно у этого плоха сама задумка, потому что хорошая и относительно не заморочанная реализация в данном случае это много костылей по исправлению фундаментально неправильного подхода к детекту задержек.

Nexius же считает, что плагин должен сам волшебным образом подстраиваться под любой скрипт (видимо, в плагин нужно ИИ вшивать, который отдельно бы, после каждой компиляции, часами изучал исходники и определял то, сколько они должны, в идеале, обрабатываться), учитывая ещё и какие-то внешние нагрузки. Правда, сколько я ни пытался от него добиться ответа, он так и не уточнил, какую в этом случае должен давать полезную информацию плагин (да и примеров из других ЯП со схожими системами дать он не смог). Ибо я не вижу ничего полезного в замерах того, какую нагрузку выдаёт мод вместе с другими процессами, запущенными в системе. Эту задачу прекрасно выполняет какой-нибудь "Диспетчер задач" из Windows или команда "ps aux" для Linux. При этом, текущее назначение данного функционала мне вполне понятно (да и примеры подобного функционала в других ЯП имеются). Но непонятый гений Nexius не слушает никакие аргументы и всё равно настаивает на своём :pardon:
Не, Nexius считает и неоднократно тебе писал о том, что плагин должен вполне себе реальными проверками учитывать внешние факторы физического сервера, на котором работает сервер самповский и иметь динамические лимиты таймингов (которые будут регулироваться фактом наличия достаточного количества доступных ресурсов для программы извне) вместо константных, которые тем более уж никак не дают реальную картину происходящего в павн скриптах, если сервер не вывозит вообще не из-за них. Дальнейшее выдуманное уже поверх всего этого посторонними челами, это, как раз, глупость. Слушать такое не нужно (да и писать тоже).

Эмм, так подбери актуальное значение для long_call_time, если уверен, что текущая конфигурация твоего скрипта работает достаточно эффективно для тебя, и не будет никаких "ложных" вызовов.
В том числе поэтому её и отключают, потому что все остальные функции крашдетекта не срут сообщениями просто так - они указывают на реальные проблемы с их реальными причинами (не следствиями). Если человеку нужен профайлер, то он может подключить конкретно его и настраивать хоть целый день. Крашдетект для других целей, и с обсуждаемой, в текущей реализации и из коробки, он явно не справляется - это очевидный факт.

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

DeimoS

20.01.2023, 16:57

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

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

А для замера скорости тех или иных реализаций для меня прекрасно подходит этот Профайлер (https://pro-pawn.ru/showthread.php?12585).

Как ты собираешься через этот профайлер проверять то, как быстро у тебя код внутри таймера срабатывает? Пол мода переносить внутрь этого профайлера, чтоб соблюсти все зависимости?
И если да, то насколько удобно будет делать это после каждой новой правки кода таймера и функций, которые вызываются в таймере? Вопрос риторический.

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

Ну вот когда у тебя секундный таймер начнёт срабатывать раз в несколько секунд из-за того, что сам код внутри таймера так долго обрабатывается - тогда и расскажешь про то, что этим не стоит заниматься. То же самое и про усиление диссинхронов из-за кода внутри OnPlayerUpdate могу сказать (это если вспоминать те примеры, которые я уже ранее называл).

а именно это люди, которые хотят следить за всем и вся

Подведу итог: ты так и не понял зачем этот функционал нужен :) Да и работой над модом для какого-нибудь работающего проекта ты так же, по всей видимости, не занимался, раз у тебя оптимизация - это сугубо "спортивный интерес". Ну либо с оптимизацией тебе везло или не везло, но ты просто на неё забивал :) Иного варианта придумать не могу.
Ну а если хочется оспорить надобность профилирования - опять же, вбивай в гугл "профилирование в программировании" и спорь с результатами, которые тебе выдаст. Можешь даже вот эту страницу на википедии (https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)) переписать, уточнив там, что всё, что написано там сейчас - глупости, ибо на самом деле профилирование нужно сугубо ради "спортивного интереса"

Той "глупости", которую и сам автор этого нововведения признаёт как дефект?

Покажи где именно он это признаёт? Что-то в PR от Y-Less (https://github.com/Zeex/samp-plugin-crashdetect/pull/78), который и добавляет данный функционал, нет ни слова про какие-то там дефекты. И есть даже те, кто прекрасно понимает зачем нужен данный функционал. Да и в других темах тоже что-то подобной истины я найти не смог. Вот есть даже неофициальный релиз (https://github.com/Zeex/samp-plugin-crashdetect/issues/104) от всё того же Y-Less, где тот фиксит баг long_time, связанный с Linux, но что-то и там нет признания, что сама идея функционала - "дефект" и на самом деле она должна работать так, как фантазируешь тут ты.
Но может я просто недостаточно долго искал. Кидай ссылки, пролей свет на ситуацию.

На остальную чушь даже отвечать не хочется. Опять начались басни про какой-то учёт внешних нагрузок. Ещё раз: покажи хоть один пример такой волшебной библиотеки в других ЯП, занимающейся тем, о чём ты тут фантазируешь, а потом уже пытайся делать вид, что твои слова имеют смысл.
Хотя давай я даже облегчу тебе задачу: просто скинь ссылку на программу или библиотеку, которая способна определять то, сколько ресурсов понадобится для работы тому или иному коду, и которая, при этом, сам этот код не воспроизводит для анализа (ой, это же невозможно :blush2:). Ты же этого хочешь получить от crashdetect (иначе непонятно как он должен "динамически" понимать какой задумывалась нагрузка от твоего кода изначально, чтоб её ещё и с внешней нагрузкой учитывать). Так давай, дерзай.

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

Nexius_Tailer

20.01.2023, 19:25

Покажи где именно он это признаёт? Что-то в PR от Y-Less (https://github.com/Zeex/samp-plugin-crashdetect/pull/78), который и добавляет данный функционал, нет ни слова про какие-то там дефекты. И есть даже те, кто прекрасно понимает зачем нужен данный функционал. Да и в других темах тоже что-то подобной истины я найти не смог. Вот есть даже неофициальный релиз (https://github.com/Zeex/samp-plugin-crashdetect/issues/104) от всё того же Y-Less, где тот фиксит баг long_time, связанный с Linux, но что-то и там нет признания, что сама идея функционала - "дефект" и на самом деле она должна работать так, как фантазируешь тут ты.

Опять начались басни про какой-то учёт внешних нагрузок. Ещё раз: покажи хоть один пример такой волшебной библиотеки в других ЯП, занимающейся тем, о чём ты тут фантазируешь, а потом уже пытайся делать вид, что твои слова имеют смысл.
Тык (https://i.imgur.com/ugBDEO3.png) (пару раз ещё обсуждалось в других каналах помимо omp-support, но этого вполне хватает). Фантазирую тут не я, как видишь. В собственном форке, который я здесь же скинул ранее, Y_less пофиксил лишь некоторые, самые очевидные и легко поддающиеся фиксу косяки, а с остальным скорее всего пока просто решил не заморачиваться, потому что сам прекрасно понимает объём работы до той кондиции, когда это станет нормально выполняться из коробки (хотя этому человеку в целом было и ранее свойственно предлагать изменения, долгосрочную ответственность за работоспособность которых он нести не был намерен, но здесь начали жаловаться на его же YSI при подключенном крашдетекте, так что ему пришлось поднапрячься и всё таки сделать с этим что-то. И как видно, не на стороне YSI).

В том, как она должна работать, был также диалог в дс. Мне, как скриптеру, в конечном итоге было бы совершенно безразлично, каким именно образом он полностью исправит последствия своей кривой проверки, но вышеописанное мною предложение я ему адресовал. Собственно, просьба что-то показать из примеров в других яп/проектах также не имеет смысл и лишь дальше уведёт тему в твоё любимое переливание из пустого в порожнее, чтобы её удовлетворять. Ключевая тема обсуждения - кривая работа long_call_time, которая кривой быть не перестаёт, пока её не исправят каким-либо образом (будь то втупую повышение константной величины задержки, встроенное игнорирование первых нескольких секунд с момента старта сервера или прочие костыли, а может и что-то подобное тому, что предложил я, при условии, что это вообще возможно - мне, как и другим, параллельно, как он собирается разрешать свои косяки, но я что-то предлагаю).

То, что она включена по умолчанию и кому-то не нужна - это не делает её бесполезной или сломанной.
Напомню, что мы не качество и удобство плагина crashdetect тут обсуждаем. Мы обсуждаем то, является ли профайлер, встроенный в crashdetect, сломанным или же всё же кто-то не смог/не захотел понять то, как пользоваться тем функционалом, который ему предоставили.
Да, все кругом не понимают, сплошь и рядом. Всё проще: никто не использует крашдетект как профайлер, ровно как и не используют профайлер в целях, для которых был создан крашдетект. Когда надо отловить ошибки и краши в рантайме - подключают первое, которое (до последней диагностики) выдавало причину любой сообщаемой проблемы. Обсуждаемая диагностика её не выдаёт, что абсолютно в этот плагин и не вписывается (в дополнение к тому, что это ещё и имеет подавляющее большинство ложных срабатываний без их фикса вручную в каждой области их возникновения, а передергивание на то, что мы тут что-то "настраиваем", пытаясь не замечать, что строим велосипеды для обхода ложных, совсем ни на кого не работает, увы).

Кстати,

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

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

punkochel

20.01.2023, 21:41

Как ты собираешься через этот профайлер проверять то, как быстро у тебя код внутри таймера срабатывает? Пол мода переносить внутрь этого профайлера, чтоб соблюсти все зависимости?
И если да, то насколько удобно будет делать это после каждой новой правки кода таймера и функций, которые вызываются в таймере? Вопрос риторический.
Все-же отвечу. Я вообще не буду проверять целые куски кода. Я проверю лишь то, на сколько сильно я потеряю в производительности, если буду вызывать системы через функции, использовать рекурсию или построить циклическую систему и т.д. Совсем в экзотических случаях, я посмотрю asm-листинги.
Если моя функция предполагает использование конструкции "цикл в цикле", то я не буду судорожно дрожать от её использования и городить системы вроде итераторов чтобы избавиться от вложенного цикла путем выискивания всех случаев когда необходимо изменить значение итератора. Возможно это где-то по дилетантски, но зато все ясно и понятно.

Ну и сразу говорю, что любые дальнейшие сообщения, никак не вносящие в обсуждение какой-либо конструктив (то бишь, если не будет пруфов тем или иным высказываниям), будут считаться оффтопом и выпиливаться согласно правилам форума. Так что советую заранее подумать, стоит ли трать время на то, чтоб в очередной раз метнуть стрелки, не оставив никаких ссылок, подтверждающих свои высказывания.
Самое интересное что инициатором был именно ты. И все сообщение в данной теме после #13 не несут в себе никакой полезной информации, а лишь какие-то обвинения что этот не знает этого, а тот не знает того. Не нужно было по крайней мере переходить на личности, а свою точку зрения касаемо long_call_time описать непредвзято и решение оставить за человеком который прочитает все это, ибо для кого-то эта функция полезна, а для кого то совсем наоборот.
То что ты считаешь правильным, не обязывает других так думать, даже если они явно не правы. Ты же видел код YSI? - Да там черт ногу сломит, и попробуй доказать Y-Less что он не прав.

UPD:
Я вообще пишу без crashdetect :)

DeimoS

14.02.2023, 18:11

Тык (https://i.imgur.com/ugBDEO3.png) (пару раз ещё обсуждалось в других каналах помимо omp-support, но этого вполне хватает).

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

Опять же, копаемся в репозитории crashdetect и находим там вот такую тему - https://github.com/Zeex/samp-plugin-crashdetect/issues/82 - в которой Y-Less продолжает утверждать, что всё работает так, как задумывалось (спустя ~5 месяцев после первого PR). Как-то не сходится с твоими утверждениями...

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

Я лишь заметил, что ты так и не понял сути написанного мной, раз говоришь про какое-то "задирание константной задержки". Впрочем, и по остальному написанному тобой оно видно.

Давай я тебе на простых примерах покажу принцип применения функций плагина, раз ты так и не осилил их.
Собственно, вот:
#include <a_samp>
#include <crashdetect>

main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}

public OnGameModeInit()
{
/*
Нас не интересует то, как долго грузится OnGameModeInit,
так что просто "отключаем" проверку времени для этого коллбэка.

Используем SetCrashDetectLongCallTime, а не DisableCrashDetectLongCall,
так как с "DisableCrashDetectLongCall" мы можем получить ложное при
следующем включении и это самый простой способ обхода ложного срабатывания
(по крайней мере из тех, что мне известны)
*/
SetCrashDetectLongCallTime(cellmax);

SetTimer("@__SomeTimer", 1000, true);
}

@__SomeTimer();
@__SomeTimer()
{
/*
Представим, что нам крайне важно, чтоб код внутри этого таймера срабатывал не более, чем за секунду, дабы
следующее срабатывание таймера произошло без задержек
(не будем учитывать погрешность нативных таймеров, представив, что у нас включен плагин с их фиксом)
*/
EnableCrashDetectLongCall();
SetCrashDetectLongCallTime(1000*1000);// Включаем замер скорости обработки кода, устанавливая время в 1 секунду (1000 = 1 миллисекунда)
new ms = GetTickCount();

for(new i; i < 1_000_000; i++) {} // Пусть это будет имитацией кода, который нам нужно выполнить

printf("Таймер сработал за %d мс (%d)", GetTickCount()-ms, GetCrashDetectLongCallTime());
DisableCrashDetectLongCall();// Дабы секундная проверка не распространилась на остальной код - отключаем её
}
Это то, какой мы написали нужную нам систему в первый раз, удостоверившись, что код внутри таймера не срабатывает более, чем за 1 секунду. "Багованный" crashdetect молчит, как и положено:

https://i.imgur.com/jvzt7QI.png
*скрин в виде ссылки для тех, у кого не грузит* (https://i.imgur.com/jvzt7QI.png)

Теперь представим, что мы продолжаем работать над модом, например, в течении года и постепенно добавляем в таймер мелкие проверки и прочий незначительный код. И вот в один момент у нас получается так, что общее время обработки кода внутри таймера превышает важную нам секунду:
#include <a_samp>
#include <crashdetect>

main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}

public OnGameModeInit()
{
SetCrashDetectLongCallTime(cellmax);

SetTimer("@__SomeTimer", 1000, true);
}

@__SomeTimer();
@__SomeTimer()
{
EnableCrashDetectLongCall();
SetCrashDetectLongCallTime(1000*1000);
new ms = GetTickCount();
/*
Увеличим число итераций для увеличения времени срабатывания кода, не меняя ничего остального
*/
for(new i; i < 100_000_000; i++) {}

printf("Таймер сработал за %d мс (%d)", GetTickCount()-ms, GetCrashDetectLongCallTime());
DisableCrashDetectLongCall();
}
И, о боже, что это!? Плагин сообщает нам о том, что время обработки кода превысило важную нам секунду:

https://i.imgur.com/W2byMxM.png
*скрин в виде ссылки для тех, у кого не грузит* (https://i.imgur.com/W2byMxM.png)

Как же это так? Почему я смог реализовать функционал плагина, получив от этого пользу? Ведь он же сломан и бесполезен :scratch_one-s_head:

punkochel, сорри, но отвечать на твоё сообщение подробно не буду. Скажу лишь, что если конкретно ТЫ что-то там не делаешь - не значит, что функции плагина от этого становятся багованными (а изначально я именно эту версию Nexius оспаривал и оспариваю) :) И нет, полезную информацию все (как минимум, мои) сообщения несут. Ибо в них опровергается очередная чушь, коей в сообществе SAMP хватает.

Собственно, раз уж я дал пример того, как можно (и нужно) использовать функции плагина, не ловя, при этом, ЛОЖНЫЕ СРАБАТЫВАНИЯ (!?!), то, думаю, тему можно закрыть, дабы не плодить ещё больший оффтоп, основанный на фантазиях одного человека и "я делаю вот так, а не так" другого. Тем более, что, за время моего отсутствия на форуме, автор никаких дополнительных вопросов не задал, а значит и проблема, видимо, решена.

DeimoS

14.02.2023, 18:26

UPD: Для особо упоротых можем даже вот такой пример сделать:

#include <a_samp>
#include <crashdetect>

main()
{
print("\n----------------------------------");
print(" Blank Gamemode by your name here");
print("----------------------------------\n");
}

public OnGameModeInit()
{
SetCrashDetectLongCallTime(cellmax);

SetTimer("@__SomeTimer", 1000, true);
}

@__SomeTimer();
@__SomeTimer()
{
EnableCrashDetectLongCall();
SetCrashDetectLongCallTime(1000*1000);
new ms = GetTickCount();

static var;// Изменился только код начиная с этой строки
if(!var)
{
for(new i; i < 1_000_000; i++) {}
}
else
{
for(new i; i < 100_000_000; i++) {}
}
var = !var;// И заканчивая этой

printf("Таймер сработал за %d мс (%d)", GetTickCount()-ms, GetCrashDetectLongCallTime());
DisableCrashDetectLongCall();
}

Результат:
https://i.imgur.com/KparZgW.png
*ссылка на скрин* (https://i.imgur.com/KparZgW.png)

Как видно, плагин реагирует только на те случаи, когда включается в работу "прожорливый" цикл и код внутри таймера срабатывает более, чем за секунду (если что, сообщение от плагина приходит раньше, чем то сообщение, которое нам показывает таймер, так как "отсчёт" нужной нам секунды в плагине заканчивается раньше срабатывания кода таймера и плагин нам об этом сообщает. То бишь: "старт обработки @__SomeTimer() => прошла секунда и пришло сообщение от crashdetect => сервер закончил обрабатывать код @__SomeTimer() и выдал printf"). Ложных не наблюдается. ЧТД. :dance:

P.S. Прошу заметить, что Nexius так и не скинул ни одного примера из других ЯП с тем фантазийным функционалом, который он требует от crashdetect =) Впрочем, не в первый и, думаю, не в последний раз он ведёт себя так, как ведёт. :dntknw:
Если кто-то захочет что-то сказать по делу касаемо обсуждаемой темы - пишите в личку (вместе с тестом того, что вы хотите сюда отправить, дабы я убедился, что это не очередной оффтоп) и открою тему для вас. Закрыто.

UPD2: Ну и, по просьбе трудящихся, вот, если что, ссылка на архив со всем нужным для воспроизведения теста - *тыщ* (https://drive.google.com/file/d/1KnHU343aV8MZx_sbERovZkDvrf1oSmzN/view?usp=share_link)
Все 3 примера объединены в скрипте и переключаются сменой макроса в начале мода