В разработке Оптимизация получения Lore из ItemStack

Хочу максимально оптимизировать процесс получения данных из ItemStack (Lore, Enchantments). Они хранятся в формате JSON и частое получение вызывает повышенную нагрузку. Я уже применил кеш и для идентификации определённого ItemStack использую метод ItemStack.hashCode, но он тоже не очень лёгкий способ, как оказалось.
Поэтому возникает вопрос, как можно понять, что я уже проверял этот ItemStack более оптимизированным способом.

 

С чего ты взял что это все постоянно парсится и хранится в json? Наиболее логично что сервак 1 раз это все парсит и хранит коллекциями. Даже в коде самого CraftItemStack указаны поля коллекций под это все дело.
https://github.com/squallblade/Spig...craftbukkit/inventory/CraftMetaItem.java#L183
И получить лор через getLore должно выполнятся за константное время так как там тупо геттер

 

Здесь видно с чего взял

 

Плюсую, там прямой лист идет.

 

То что он выдает лист не означает, что он хранит в таком виде. Да и вопрос немного в другом, как идентифицировать предмет максимально быстро.

 

Как вариант:

Код:

    HashSet<ItemStack> checked = new HashSet<ItemStack>();
    private void e(ItemStack item) {
        if(checked.add(item)) {
            //предмет не был проверен
        }
    }

Код:

    HashMap<ItemStack,List<String>> cache = new HashMap<ItemStack,List<String>>();
    private List<String> ee(ItemStack item) {
        if(cache.containsKey(item)) {
            return cache.get(item);
        }
        List<String> lore=item.getItemMeta().getLore();
        cache.put(item,lore);
        return lore;
    }

(Не уверен что это максимально быстро.)

 

Хранить сам ItemStack напряжно по памяти. Кстати, я еще пробовал serialize, грузит сильнее, чем hashCode

 

Не лучше будет PDH воспользоваться, а не упарываться с кэшем?

 

Ты серьезно? https://github.com/squallblade/Spig...craftbukkit/inventory/CraftMetaItem.java#L408
Там тупо прямой лист, а нагрузка у тебя мб потому что ты, незнаю, 1000 раз в тик его получаешь?
Да и по скрину видно что у тебя нагрузка этим методом 0.32% от всей общей нагрузки. Ты понимаешь насколько это мало?

Невозможно такое чтобы там был постоянный парсинг, это неразумно + те же paper давно бы этот бред фиксанули.
Не страдай фигней)

 

Всё уже давно на компонентах стоит. Да и по spark'у видно трансформации.
https://hub.spigotmc.org/stash/proj.../craftbukkit/inventory/CraftMetaItem.java#879

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

 

1.19.4 это тебе не 1.8

 

Хотя, стоп, 2013 год, это наверно 1.7 или 1.6. Какой смысл основываться на репозиториях прошлого века=)

 

И да, извиняюсь за скрин с телефона. Вот ссылка на тайминги - https://spark.lucko.me/jKjgZDmnJc

И главное: зачем спорить про способ доставания данных, когда вопрос в другом: как идентифицировать предмет, чтобы не повторять процесс его полной проверки?

 

Повторюсь - вместо проверки лора предмета лучше использовать PDH.

 

Ну если сильно хочется, то можно через рефлексию(MethodHandles) доставать сырой лор, и просто работать с JSON строками на прямую, через contains там например.
Еще возможно если использовать только PaperApi, то возможно методы которые сразу возвращают Component, используют сразу кэшированные компоненты, а из них поидее можно просто достать текст, которых хранится в компоненте.