- Сообщения
- 385
- Решения
- 4
Ну попробуй замерить, сколько итемстак занимает места в памяти и сколько стоит его инициализация, а зачем тебе такое? Это бутылочное горлышко?
Вообще - по моему опыту ни разу такого небыло, чтобы из-за открытия менюшек была хоть призрачная тень на проблемы с производительностью
Другое дело - писать код не оптимально не позволяет мне моя совесть
Зависит от того, насколько далеко ты готов зайти ради оптимизации
Когда писал свой аналог DeluxeMenus (ядро на к-ром я сижу не поддерживает его) я использовал следующие подходы для оптимизации:
0. Конфиги - TsonConfigurations, быстрее json и yaml вместе взятых и перемноженных на 2, бонусом имеет огромное к-во плюшек
1. Виртуализация инвентарей. Никаких событий - все работает через стандартный механизм наследования. Просто открываю свой "унаследованный" контейнер в к-ром переопределены нужные методы.
2. Для масштабирования, используется специальный интерфейс-фабрика, для создания предмета которые нужно поместить в указанные слот(ы).
2.1 Если предмет не изменяется - используется фабрика, к-я сразу создает предмет и хранит его внутри себя - и по необходимости передает указатель на него.
2.1.2 Если данный предмет используется в слоте, с которым игрок может взаимодействовать (брать, ложить, изменять) - возвращается не предмет а его копия
2.1.3 Так же создается постоянный байтовый буфер куда записывается данный предмет (предварительная подготовка для создания пакета) (Когда отправляется пакет с контентом для открытого инвентаря - можно быстро перекопировать буфер в пакет + можно сразу рассчитать необходимый размер буфера пакета)
2.2 Если предмет изменяется (имеет подстановки) - используется фабрика к-я сохраняет ноду конфигурации в json (без пробелов и лишних символов), преобразует в LSFPS-формат, (запоминает указатели на места, куда вставлять подстановки и прямые указатели на функции подстановок) (в качестве провайдеров для подстановок указаны глобальный и спец. провайдер подстановок для меню). При запросе - оно быстренько форматирует "конфиг", считывает предмет и сразу возвращает результат
условно в том же аукционе, и так очень много предметов создаётся
TheFaser
Пользователь
- Сообщения
- 112
- Решения
- 1
Создание предметов не является узким местом, объект предмета довольно простой и в себе мало чего содержит. Максимум ты можешь закешировать создание кастомных предметов с текстурами, чтобы каждый раз их не билдить
а кешировать значения из конфига, какие нибудь сообщения например имеет смысл?
TheFaser
Пользователь
- Сообщения
- 112
- Решения
- 1
Сами строки? В зависимости от того, как у тебя работает конфигурация. Я лично использую реализацию через классы, когда конфигурация десериализуется из yaml файла, по сути и являясь "кешом", потому что объект уже создан и обращение к нему моментальное (можешь глянуть Jackson или если попроще, то elytrium serializer). Если у тебя дефолтная система, которая предоставляется самим спиготом, то там наверное да, не стоит каждый раз дёргать её, а лучше вначале получить и использовать
спасибо