Предложу свой форк foreach от ziggi: https://github.com/punkochel/foreach
Тут просто добавлена совместимость с open.mp в силу изменений GetPool*Size, при инициализации инклуда.
Предложу свой форк foreach от ziggi: https://github.com/punkochel/foreach
Тут просто добавлена совместимость с open.mp в силу изменений GetPool*Size, при инициализации инклуда.
Можно было бы заодно тогда и fixes.inc учитывать, т.к. он их поведение также менял.Цитата:
Сообщение от punkochel
Да, спасибо. Добавлю.
Как я понимаю, вопрос решён?
Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.
Открыть/закрыть
Я согласен с Nexius. Дело в том что определять long_call_time для pawn-скриптов не самое лучшее занятие. pawn.cc это самый примитивный компилятор, который мало что умеет оптимизировать и ни о каких inline-функциях тут и речи не идет.Цитата:
Сообщение от DeimoSКак я понимаю, вопрос решён?
Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.
Если мы в GameModeInit вызовем функцию, которая создает объекты на сервере, то мы в любом случае получим сообщение long_call_time.
Если-же мы пишем мод в одном файле, дублируя многие участки кода и т.д. то наверное мы могли бы добиться чуть большей производительности. Но если мы пишем "модульный" мод, в котором системы раскиданы по различным директориям и использование модулей осуществляется через функции, то long_call_time будет выдавать нам сообщение довольно часто, а об использовании рекурсии можно вообще забыть, если бояться подобных сообщений.
UPD:
Да, на beta стадии можно ради спортивного интереса посмотреть какие функции нагружают систему сильнее, но как таковой практической пользы эта функция не несет.
Эмм, так подбери актуальное значение для long_call_time, если уверен, что текущая конфигурация твоего скрипта работает достаточно эффективно для тебя, и не будет никаких "ложных" вызовов.Цитата:
Сообщение от punkochel
Ты, видимо, тоже не особо понимаешь как работает "long_call_time", судя по написанному. Ибо всё, что она делает - замеряет то, как долго обрабатывается код в коллбэке, после сверяет результат со значением из "long_call_time" и если первое превышает второе - выдаёт предупреждение. Соответственно, всё, что тебе нужно - это замерить то, сколько у тебя обрабатывается тот же OnGameModeInit, а после вызвать в нём же "SetCrashDetectLongCallTime" и указать в неё замеренное ранее время с некоторым запасом. Всё, "ложные" срабатывания волшебным образом прекратились.
А можешь поступить ещё более невероятным образом: отключить данный функционал через вызов "DisableCrashDetectLongCall" в OnGameModeInit для всего мода, а после включать его (EnableCrashDetectLongCall/SetCrashDetectLongCallTime) только для тех функций, время обработки которых тебе хотелось бы контролировать.
В общем, как я уже как-то говорил Nexius - все ваши "ложные" срабатывания сугубо от того, что вы не понимаете для чего нужен данный функционал и как именно его использовать. Хотя вообще профилировщик - это достаточно тривиальная штука. И на тот же плагин "profiler" почему-то никто не кидается с криками: "Он сообщает мне о том, что мой код работает медленно!". А когда тот же самый профилировщик вставили в crashdetect (плагин, который существует для дебага), некоторые вдруг не опознали в профилировщике профилировщика (да и вообще, судя даже по твоему сообщению, не особо поняли с чем имеют дело и каким оно должно, по их мнению, быть на самом деле) и начали говорить про какой-то кривой функционал.
Ну и сразу говорю, что какого-то срача тут не будет (а если кто-то захочет начать - он быстро исчезнет). Расписываю всё это сугубо для тех, кто не понимает зачем нужен "long_call_time". Если же у кого-то всё ещё осталось желание оспорить сказанное мной - вбивайте в гугл "профилирование в программировании" и спорьте с ним.
Эмм, весь плагин "crashdetect" создан для отладки кода. Пускать вместе с ним сервер в прод = замедлять и без того не шустрый Pawn.Цитата:
Сообщение от punkochel
А касаемо "спортивного интереса": ну когда ты будешь писать код либо на заказ, либо с целью создать что-то серьёзное, а не просто скриптики для себя в свободное время - тогда и поймёшь, зачем может понадобиться контролировать те или иные участки кода на предмет того, что они не обрабатываются дольше определённого времени (например, проверять то, что секундные таймеры срабатывают именно за секунду? Или что код в OnPlayerUpdate не вызывает серьёзных задержек?). И тут ты уже вспомнишь о "long_call_time", поблагодарив Y_Less за него, ибо тебе не придётся изобретать собственный велосипед или же пытаться вычленить нужную информацию из отчёта плагина "profiler", а будет готовое решение, которое легко интегрируется и управляется. Ну либо, потенциально, в проде игроки поймают лаги/диссинхроны и тебе придётся впопыхах страдать над оптимизацией :pardon:
Не понимаю почему ты так к этому прицепился. Но лично для меня, да и думаю что многих других тоже, эта функция скорее помеха чем фича, потому-то необходимо тратить время на её отключение, так как она включена по умолчанию. А для замера скорости тех или иных реализаций для меня прекрасно подходит этот Профайлер. Ну а замерять целые куски кода, которые определяются совокупностью тех или иных реализаций, как по мне это не то чем нужно заниматься.
В общем, не спорю, для кого-то это несомненно полезный функционал, а именно это люди, которые хотят следить за всем и вся, а при виде сообщения от long_call_time бегут сразу смотреть что к чему, тратят массу времени на замеры и исправления (дай Бог если получиться исправить) того, что и так работает как должно.
Подведу итог:
В наше время программируя на pawn и при этом цепляться за каждый упущенный такт процессора это весьма сомнительная работа. Сейчас даже микроконтроллеры в будильнике мощнее чем в инженерных калькуляторах 2000-х годов.
Подобное можно сравнить вот с этим:
Той "глупости", которую и сам автор этого нововведения признаёт как дефект? Из предыдущего диалога это ты отказываешься понимать очевидную вещь: то, что даёт ложных больше, чем не ложных - изначально плохой инструмент. То, что не указывает на реальную причину, но лишь на следствие - изначально плохой инструмент. Конкретно у этого плоха сама задумка, потому что хорошая и относительно не заморочанная реализация в данном случае это много костылей по исправлению фундаментально неправильного подхода к детекту задержек.Цитата:
Сообщение от DeimoS
Не, Nexius считает и неоднократно тебе писал о том, что плагин должен вполне себе реальными проверками учитывать внешние факторы физического сервера, на котором работает сервер самповский и иметь динамические лимиты таймингов (которые будут регулироваться фактом наличия достаточного количества доступных ресурсов для программы извне) вместо константных, которые тем более уж никак не дают реальную картину происходящего в павн скриптах, если сервер не вывозит вообще не из-за них. Дальнейшее выдуманное уже поверх всего этого посторонними челами, это, как раз, глупость. Слушать такое не нужно (да и писать тоже).Цитата:
Сообщение от DeimoS
В том числе поэтому её и отключают, потому что все остальные функции крашдетекта не срут сообщениями просто так - они указывают на реальные проблемы с их реальными причинами (не следствиями). Если человеку нужен профайлер, то он может подключить конкретно его и настраивать хоть целый день. Крашдетект для других целей, и с обсуждаемой, в текущей реализации и из коробки, он явно не справляется - это очевидный факт.Цитата:
Сообщение от DeimoS
Если бы крашдетект встраивал только фичу детекта мертвых зависаний, реализация бы не потребовала большого количества ресурсов и сложности, и всё ещё была бы более-менее точной на уровне других имеющихся диагностик. Но поскольку это взяло на себя ещё и задачу по отлову просто медленно выполняющегося кода - оно должно было быть реализовано соответствующе или не включено по умолчанию, чтобы каждый первый потом не хотел это отключать после того, что он видит в консоли на вполне адекватно и эффективно работающем алгоритме своего скрипта.
То, что она включена по умолчанию и кому-то не нужна - это не делает её бесполезной или сломанной.Цитата:
Сообщение от punkochel
Напомню, что мы не качество и удобство плагина crashdetect тут обсуждаем. Мы обсуждаем то, является ли профайлер, встроенный в crashdetect, сломанным или же всё же кто-то не смог/не захотел понять то, как пользоваться тем функционалом, который ему предоставили.
Как ты собираешься через этот профайлер проверять то, как быстро у тебя код внутри таймера срабатывает? Пол мода переносить внутрь этого профайлера, чтоб соблюсти все зависимости?Цитата:
Сообщение от punkochel
И если да, то насколько удобно будет делать это после каждой новой правки кода таймера и функций, которые вызываются в таймере? Вопрос риторический.
Ну вот когда у тебя секундный таймер начнёт срабатывать раз в несколько секунд из-за того, что сам код внутри таймера так долго обрабатывается - тогда и расскажешь про то, что этим не стоит заниматься. То же самое и про усиление диссинхронов из-за кода внутри OnPlayerUpdate могу сказать (это если вспоминать те примеры, которые я уже ранее называл).Цитата:
Сообщение от punkochel
Подведу итог: ты так и не понял зачем этот функционал нужен :) Да и работой над модом для какого-нибудь работающего проекта ты так же, по всей видимости, не занимался, раз у тебя оптимизация - это сугубо "спортивный интерес". Ну либо с оптимизацией тебе везло или не везло, но ты просто на неё забивал :) Иного варианта придумать не могу.Цитата:
Сообщение от punkochel
Ну а если хочется оспорить надобность профилирования - опять же, вбивай в гугл "профилирование в программировании" и спорь с результатами, которые тебе выдаст. Можешь даже вот эту страницу на википедии переписать, уточнив там, что всё, что написано там сейчас - глупости, ибо на самом деле профилирование нужно сугубо ради "спортивного интереса"
Покажи где именно он это признаёт? Что-то в PR от Y-Less, который и добавляет данный функционал, нет ни слова про какие-то там дефекты. И есть даже те, кто прекрасно понимает зачем нужен данный функционал. Да и в других темах тоже что-то подобной истины я найти не смог. Вот есть даже неофициальный релиз от всё того же Y-Less, где тот фиксит баг long_time, связанный с Linux, но что-то и там нет признания, что сама идея функционала - "дефект" и на самом деле она должна работать так, как фантазируешь тут ты.Цитата:
Сообщение от Nexius_Tailer
Но может я просто недостаточно долго искал. Кидай ссылки, пролей свет на ситуацию.
На остальную чушь даже отвечать не хочется. Опять начались басни про какой-то учёт внешних нагрузок. Ещё раз: покажи хоть один пример такой волшебной библиотеки в других ЯП, занимающейся тем, о чём ты тут фантазируешь, а потом уже пытайся делать вид, что твои слова имеют смысл.
Хотя давай я даже облегчу тебе задачу: просто скинь ссылку на программу или библиотеку, которая способна определять то, сколько ресурсов понадобится для работы тому или иному коду, и которая, при этом, сам этот код не воспроизводит для анализа (ой, это же невозможно :blush2:). Ты же этого хочешь получить от crashdetect (иначе непонятно как он должен "динамически" понимать какой задумывалась нагрузка от твоего кода изначально, чтоб её ещё и с внешней нагрузкой учитывать). Так давай, дерзай.
Ну и сразу говорю, что любые дальнейшие сообщения, никак не вносящие в обсуждение какой-либо конструктив (то бишь, если не будет пруфов тем или иным высказываниям), будут считаться оффтопом и выпиливаться согласно правилам форума. Так что советую заранее подумать, стоит ли трать время на то, чтоб в очередной раз метнуть стрелки, не оставив никаких ссылок, подтверждающих свои высказывания.
Тык (пару раз ещё обсуждалось в других каналах помимо omp-support, но этого вполне хватает). Фантазирую тут не я, как видишь. В собственном форке, который я здесь же скинул ранее, Y_less пофиксил лишь некоторые, самые очевидные и легко поддающиеся фиксу косяки, а с остальным скорее всего пока просто решил не заморачиваться, потому что сам прекрасно понимает объём работы до той кондиции, когда это станет нормально выполняться из коробки (хотя этому человеку в целом было и ранее свойственно предлагать изменения, долгосрочную ответственность за работоспособность которых он нести не был намерен, но здесь начали жаловаться на его же YSI при подключенном крашдетекте, так что ему пришлось поднапрячься и всё таки сделать с этим что-то. И как видно, не на стороне YSI).Цитата:
Сообщение от DeimoS
В том, как она должна работать, был также диалог в дс. Мне, как скриптеру, в конечном итоге было бы совершенно безразлично, каким именно образом он полностью исправит последствия своей кривой проверки, но вышеописанное мною предложение я ему адресовал. Собственно, просьба что-то показать из примеров в других яп/проектах также не имеет смысл и лишь дальше уведёт тему в твоё любимое переливание из пустого в порожнее, чтобы её удовлетворять. Ключевая тема обсуждения - кривая работа long_call_time, которая кривой быть не перестаёт, пока её не исправят каким-либо образом (будь то втупую повышение константной величины задержки, встроенное игнорирование первых нескольких секунд с момента старта сервера или прочие костыли, а может и что-то подобное тому, что предложил я, при условии, что это вообще возможно - мне, как и другим, параллельно, как он собирается разрешать свои косяки, но я что-то предлагаю).
Да, все кругом не понимают, сплошь и рядом. Всё проще: никто не использует крашдетект как профайлер, ровно как и не используют профайлер в целях, для которых был создан крашдетект. Когда надо отловить ошибки и краши в рантайме - подключают первое, которое (до последней диагностики) выдавало причину любой сообщаемой проблемы. Обсуждаемая диагностика её не выдаёт, что абсолютно в этот плагин и не вписывается (в дополнение к тому, что это ещё и имеет подавляющее большинство ложных срабатываний без их фикса вручную в каждой области их возникновения, а передергивание на то, что мы тут что-то "настраиваем", пытаясь не замечать, что строим велосипеды для обхода ложных, совсем ни на кого не работает, увы).Цитата:
Сообщение от DeimoS
Кстати,
заметь, все описываемые тобою случаи прекрасно покрывались бы, если бы даже с текущими методами работы сама константная задержка была задрана так, чтобы ловить аномально долгие выполнения, даже безотносительно производительности физического сервера. Т.е. ты пытаешься защищать то, что реализовано плохо даже с той задумкой, которая есть сейчас.Цитата:
Сообщение от DeimoS
Ну и сразу говорю, что непониманию, по какой причине ты адресуешь это мне, учитывая, что я всегда веду разговор по теме, а любые отклонения от неё как правило на собеседнике (тебе ли этого не знать). Советую просто принимать вещи такими, какие они есть, даже если очень хочется с кем-то поспорить. В данной ситуации уже не первый раз тебе предоставляют аргументы по одной и той же теме обсуждения, по которой уже говорили и ставили точку в прошлый.Цитата:
Сообщение от DeimoS