Помогите Как записать число в HashMap?

Ну на счёт производительности я сомневаюсь, но это точно удобнее.
Производительность выше, так как:
  1. Мы храним связку Map-Entry-Value-[Fields], а не Map1-Entry1-Map2-[Entry2-Field].
  2. Мы используем put() и get() для доступа только один раз, а не два.
  3. Доступ к полям объекта напрямую быстрее работы с коллекцией.
  4. Мы имеем возможность использовать примитивы, а не только обёртки.
 
Ну на счёт производительности я сомневаюсь (только давайте без замеров затрат наносекунд), но это точно удобнее.
Имхо, это изич. В конце концов, java это ООП, а не процедурный яп.
Ну тут и не поспоришь, но тс похоже начал сразу с плагинов, но не с java
 
Производительность выше, так как:
  1. Мы храним связку Map-Entry-Value-[Fields], а не Map1-Entry1-Map2-[Entry2-Field].
  2. Мы используем put() и get() для доступа только один раз, а не два.
  3. Доступ к полям объекта напрямую быстрее работы с коллекцией.
  4. Мы имеем возможность использовать примитивы, а не только обёртки.
Я же просил, что не нужно меряться затратами наносекунд.
Ну тут и не поспоришь, но тс похоже начал сразу с плагинов, но не с java
Ну а я начинал с сурсов ванильного майнкрафта, а потом уже с книжек по жабке. Последние после моджанговского поделия весьма скучны :D
 
Я же просил, что не нужно меряться затратами наносекунд.
Ну а я начинал с сурсов ванильного майнкрафта, а потом уже с книжек по жабке. Последние после моджанговского поделия весьма скучны :D
Я с хака лаунчеров начинал.
 
Я с хака лаунчеров начинал.
D83DDE11.png
 
Я же просил, что не нужно меряться затратами наносекунд.
Извиняюсь. Просто сегодня мне жаловались на производительность одной функции Forestry, вот мой внутренний оптимизатор и проснулся.
Как оказалось, тормоза были из-за огромного количества вызовов метода OreDictionary.getOreIDs(ItemStack), в котором авторы Forge тоже решили не мерить наносекунды. Итог: создание коллекции -> копирование в неё ещё двух коллекций -> экспорт в массив Integer -> экспорт в массив int -> дикие тормоза.
 
Извиняюсь. Просто сегодня мне жаловались на производительность одной функции Forestry, вот мой внутренний оптимизатор и проснулся.
Как оказалось, тормоза были из-за огромного количества вызовов метода OreDictionary.getOreIDs(ItemStack), в котором авторы Forge тоже решили не мерить наносекунды. Итог: создание коллекции -> копирование в неё ещё двух коллекций -> экспорт в массив Integer -> экспорт в массив int -> дикие тормоза.
Про фордж даже начинать не стоит, он по жизни тормозной.
 
Извиняюсь. Просто сегодня мне жаловались на производительность одной функции Forestry, вот мой внутренний оптимизатор и проснулся. Как оказалось, тормоза были из-за огромного количества вызовов метода OreDictionary.getOreIDs(ItemStack), в котором авторы Forge тоже решили не мерить наносекунды. Итог: создание коллекции -> копирование в неё ещё двух коллекций -> экспорт в массив Integer -> экспорт в массив int -> дикие тормоза.
Ну там решили не мерить миллисекунды, а это уже чревато.
Да я не такой как все. Я изучал не с java кода, а с бинарников в ждгуи :D.
Страшный человек ты.
Про фордж даже начинать не стоит, он по жизни тормозной.
Ну тут не про фордж, а лишь про один метод.

За сим предлагаю свернуть лавочку, ибо многовато намусорили не по теме.
 
Я же просил, что не нужно меряться затратами наносекунд.
Ну а я начинал с сурсов ванильного майнкрафта, а потом уже с книжек по жабке. Последние после моджанговского поделия весьма скучны :D
Разве в бакките есть объяснение, что такое ООП и как его есть?)
 
И только я пользуюсь классами для хранения мультизначений?:D
Java:
public class Meta {
    private final String type;
    private int value;
    private boolean isNecessary;
    public Meta(String type, int value, boolean isNecessary) {
        this.type = type;
        this.value = value;
        this.isNecessary = isNecessary;
    }
    //ну и дальше инкапсуляции и нужные мне методы
}

Java:
private final HashMap<String, Meta> metas = new HashMap<>();
++
 
Назад
Верх