Не волнуйся, если вдруг мне придется писать что то, и что конечно маловероятно писать мод, то он не задохнется от не оптимизированного кода
Вид для печати
Он будет задыхаться от кучи других неоптимизированных функций, если уж совсем забить на оптимизацию. То же самое и с памятью: сегодня ты забил на подсчёт в одном месте, завтра в другом, послезавтра в третьем - и через неделю получил выход за пределы массива и скрипт в 100 строк, который компилируется по 3 минуты.
От того, что ты начнёшь использовать сторонние функции, а не нативные, удобства меньше не станет (ну разве что у тебя не синдром утёнка). И от того, что ты раз напишешь новую, более быструю функцию (подключишь плагин, повышающий скорость обработки кода/воспользуешься сторонней библиотекой и т.п.), ты так же ничего не потеряешь, а лишь приобретёшь.
И да, касаемо той же GetNumberOfArguments. Мне казалось, что адекватный человек понимает, что сию функцию есть смысл использовать только в местах, где частота вызова кода огромная и скорость его выполнения очень значима. И, как мне казалось, ни автор, ни кто либо ещё не предлагал повсеместно заменять numargs на эту функцию. Автор просто показал, что можно сделать быстрее, а уже понадобиться тебе эта функция или нет - никого, кроме тебя, это не волнует.
Хотя, судя по твоей упёртости, ты весь код пишешь под копирку, не думая о том, что где-то нужно больше уделить оптимизации памяти, а где-то - оптимизации скорости. А судя по одному из последних сообщений, дальше теории ты так и не уходил. Ну не суть.
Только использовать нативную функцию, но чуть медленней и целенаправленно писать говнокод - разные вещи. Реально игрок оценит лишь плохо работающий алгоритм по эффективности, а не микрооптимизации (хотя конечно, в каких-нибудь циклах или ещё каких-то слабых местах лучше и максимально стараться время выполнения сокращать). Так что это скорее крайности.
Ок, я на самом деле давно уже в курсе об уязвимости в lref.s.pri/alt (недавно зарепортил её и ещё несколько других разработчику Pawn), просто хотел проверить знание теории.
Касаемо реализации, никогда не считал использование уязвимостей хорошим тоном - скорее, грязным хаком, коим это дело и является. Также остаётся под вопросом совместимость с JIT. Насколько помню, код инициализации в y_amx в сочетании с JIT вызывает краш как раз на моменте выполения инструкции lref.s.pri.
Кроме того, непонятно, в какой реальной ситуации может пригодиться такая функция - разве что в какой-нибудь библиотеке с кучей других хаков, наподобие y_amx, в которой реализован командный процессор и прочие поделия, которые по-хорошему следовало бы делать без всяких костылей в виде плагина.