Сообщений в теме: 156

[Pringles]

А как вообще это работает  Tickrate Enabler 1.4.2 - просто кидаешь в adoons  и все на этом?

[BHaType]

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

 

И каждый плагин вместо того чтобы к примеру подписываться на событие урона и выяснять кучей проверок выживший ли это который получает урон от танка - может просто сразу использовать функцию SurvivorTakesDamageFromTank(). 

 

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

Как по мне, лучше всё в 1 плагин запихать.

[BloodyBlade]

Как по мне, лучше всё в 1 плагин запихать.

Предлагаешь делать как на supercoop серверах? Т.е. почти все нужные функции и операции собрать в 1 главный плагин?

[BHaType]

Предлагаешь делать как на supercoop серверах? Т.е. почти все нужные функции и операции собрать в 1 главный плагин?

Имею ввиду, что можно все имеющийся плагины собрать в 1(не только функции), а прям таки всё что только есть(не считая стандартных плагинов соурса).

[anarki1980]

Имею ввиду, что можно все имеющийся плагины собрать в 1(не только функции), а прям таки всё что только есть(не считая стандартных плагинов соурса).

 

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

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

И потом - у меня 900 кб текста исходников, полгода ушло на то что бы это все отладить до идеала, сколько уйдет на то чтобы слепить это все в единую забагованную массу я не хочу думать

С форвардами была бы выгода по экономии операций, и отсутствие гемора, но сам вызов мне кажется даже с виду емким.

[BloodyBlade]

Имею ввиду, что можно все имеющийся плагины собрать в 1(не только функции), а прям таки всё что только есть(не считая стандартных плагинов соурса).

Я это и имел ввиду.
По этой причине SuperCoop и привёл в пример. Т.к. на супер коопах обычно почти все плагины в одном, и этот главный плагин для компиляции требует исходники и инклюды тех плагинов, которые в него включены.

Сообщение отредактировал BloodyBlade: 21 Февраль 2019 - 15:04

[BHaType]

В любом случае, каждый делает по своему.

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

И если уж юзать хуки(SDKHook), то постараться юзать их только в 1 плагине.

[AlexMy]

Скрытый текст

Это бред и не более.

[Game Over - L4D2 - CS:GO]

Где-то это уже обсуждалось и из этого ничего хорошего не выйдет, вроде как есть что-то вроде лимита и плагины с очень большим функционалам не будут вести себя корректно. Представьте сколько там строчек будет 500 000 как минимум, а у кого-то и за 90 плагинов, могу и ошибаться сам не исследовал, но проверять это не вижу разумным. Да и обсуждали далеко не новички. Слишком много времени будет затрачено, чтобы получить разочарование. Даже если это будет работать, то как минимум будет каша и неудобно всем этим пользоваться, а потом ещё это нужно будет обновлять и как там найти ошибки?) 

[anarki1980]

Где-то это уже обсуждалось и из этого ничего хорошего не выйдет, вроде как есть что-то вроде лимита и плагины с очень большим функционалам не будут вести себя корректно. Представьте сколько там строчек будет 500 000 как минимум, а у кого-то и за 90 плагинов, могу и ошибаться сам не исследовал, но проверять это не вижу разумным. Да и обсуждали далеко не новички. Слишком много времени будет затрачено, чтобы получить разочарование. Даже если это будет работать, то как минимум будет каша и неудобно всем этим пользоваться, а потом ещё это нужно будет обновлять и как там найти ошибки?) 

 

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

[dr_lex]

Внесу и я свою ленту

1. Например supertank++ - там основной плагин с 30шт модулями к нему. Все это чудо на версии v5.80 употребляет два раза больше, чем вся моя сборка сервера

Для информации
Один плагин занимает около 5-6кб памяти на сервере, а если на сервере 100шт плагинов? то это будет уже 600кб занято в пустую. А там ещё функции и cvar отбирают память, в итоге серверу надо огромные ресурсы.

2. Если взять в пример с surepcoop то будет экономия в памяти, но будет беда с кодом.

Вывод: надо добавлять на сервер все в меру. И делать несколько основных плагинов, но с отдельными inc под каждую функцию (чтобы можно было отключать и включать).
Как пример реализации можно посмотреть в теме Инструкция как собрать сборку Hardmod

Сообщение отредактировал dr_lex: 22 Февраль 2019 - 22:39

[anarki1980]

Наверное я плохо формулирую вопросы.

Пример конкретный приведу: у меня 3 плагина использующих функцию OnPlayerRunCmd()

Она вызывается для каждого клиента 100 раз в секунду, итого 300 раз * 8 клиентов = 2400 раз в секунду. 

В этой функции обязательные проверки номера клиента это 2 операции + 5 стандартных функций. Умножаем их на 2400 в сек. Это не берется в расчет что могут быть и другие смысловые уже функции, которые берут аргументы в виде строк (что супер затратно) типа GetEntProp(i, Prop_Send, "m_zombieClass").

 

А вопрос вот в чем: если сделать один плагин с функцией OnPlayerRunCmd() и 800 раз в секунду вызывать форварды в трех плагинах передавая туда уже проверенные номера клиентов, будет ли это быстрее?

 

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

 

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

[Ren89]

лепту

не пойму смысл этих вычислений - 600 кб из 2 гб это 0.3%, а из 4 гб так вообще 0.15%

хотя в целом все верно ты сказал

я объединял тяжелые функции из плагинов вместе, например runcmd, sdkhook's, gameframe и т.д.

и не очень тяжелые тоже, в общем все до чего дотянулся пока не надоело

из ~150 плагинов у меня получилось меньше 30, это с учетом стандартных от сурсмода

вывод такой что если есть время и можешь это же сделать, а после сможешь после с таким большим плагином работать, то почему нет

лучше будет, но не сказать бы что прям намного

Сообщение отредактировал Ren89: 23 Февраль 2019 - 12:46

[dr_lex]

лепту

не пойму смысл этих вычислений - 600 кб из 2 гб это 0.3%, а из 4 гб так вообще 0.15%

хотя в целом все верно ты сказал

я объединял тяжелые функции из плагинов вместе, например runcmd, sdkhook's, gameframe и т.д.

и не очень тяжелые тоже, в общем все до чего дотянулся пока не надоело

из ~150 плагинов у меня получилось меньше 30, это с учетом стандартных от сурсмода

вывод такой что если есть время и можешь это же сделать, а после сможешь после с таким большим плагином работать, то почему нет

лучше будет, но не сказать бы что прям намного

Смысл есть, так как не все держат сервера на мощном железе.
Вот к примеру мой сервер. От употребляет в данный момент 475545 bytes

Из них:
Plugin из 61шт – 312668 bytes

ConVar (один = 96 bytes) – 71232 bytes
А остальное это IBaseMenu, DataPack и т.д от плагинов

Я когда был на ПРО-Тарифе решил заняться оптимизацией в сторону ресурса-емкости сервера.

Да нету смысла, если держишь на ПРО-Тарифе за 2000р в месяц Но проблему это не решает!
 

 

[dragokas]

Ну и в чём разница, на 100 МБ больше или меньше при пропускной способности современных модулей памяти свыше 14 ГБ/c?

 

Plugin из 61шт – 312668 bytes

Не знаю, что там так сильно жрёт, может это во 2 части так, у меня на 1-й если считать по дельте, то 123 плагина (без sm) кушают 50 МБ. Хендлы - менее 1 МБ.

 

anarki1980

,

по-моему это все филькин труд. sm сам должен заботится об оптимизации таких вещей.

Те же IsClientInGame для 64 клиентов - это копирование пару КБ памяти из внутренней структуры, закешированной на сервере,

если ты конечно не делаешь всяких Prop_Send и обращений к ЖД. Ну а если у тебя внутри просто математика, то современные процессоры не тратят циклы при повторном перерасчете.

 

Большей оптимизации добьешься удалением или исправлением глючных плагинов, бесполезных циклов (например, выбором более оптимальных структур, вроде adt_array, KeyValues, где поиск идёт не через полный перебор, а по хеш-ключу, или вовсе через БД), заменой в циклах выделения памяти на static и кеширования в глобальные переменные дисковых данных, даже если это будет стоить много КБ памяти.

[dr_lex]

Не знаю, что там так сильно жрёт, может это во 2 части так, у меня на 1-й если считать по дельте, то 123 плагина (без sm) кушают 50 МБ. Хендлы - менее 1 МБ.

Это столько занимает памяти просто так плагины.

в консиль напиши

sm_dump_handles addons/sourcemod/handles.txt

потом выложи файл handles.txt этот сюда

[dragokas]

Я же говорю, в районе 1 МБ.

-- Approximately 1195025 bytes of memory are in use by Handles.

 

ну +4 МБ, если поставить плагин command_buffer.

 

Общее потребление - 394 MB (344 - если голый sm)

 

Left4dead 1.