Помогите Оптимизация

  • Автор темы Автор темы CoolBoy
  • Дата начала Дата начала
Шок. А что быстрей будет? Или он в equals тоже == ?
А вот тут без понятия. Equals хеш код обьектов сравнивает. У одинаковых обьектов - одинаковый хешкод. Мало того, насколько я знаю, метод equals у Player переопределён.
 
equals это как минимум обращение в таблицу виртуальных функций (а мы помним, что в Java методы все методы виртуальные), а затем ещё и ряд действий над его полями для вычисления hash. Поскольку логика сервера гарантирует, что у онлайн игрока только один Player, то лучше через ==, чему вообще обращаться по адресу в памяти, где лежат объекты, не нужно.
 
А теперь глянь пост от Reality_SC.
В смысле? Выше пост Reality_SC почитай, он объяснил. Просто примеров для сравнения приводил == и я вот не понял.
Мне легче сравнивать по имени, чем смотреть заходы и выходы игрока. Ну хотя, кому как ^_^
 
Мне легче сравнивать по имени, чем смотреть заходы и выходы игрока. Ну хотя, кому как ^_^

ну смотри, у тебя есть допустим огромнейшая коробка(сервер). в которой лежат камни(игроки) по 10 тонн(вся дата игрока). допустим 50 камней.
на каждом камне выгравировано его уникальное имя(ссылка, адрес в памяти). теперь тебе тебе подсовывают еще один камушек, снова 10 тонн, и хотят узнать есть ли среди тех 50 аналог тому что тебе дали.

естественно ты как умный тупо найдешь камушек с таким же именем (проверка по ссылке), однако те кто сунули тебе этот камень хотят что бы ты проверил его по всем параметрам (Equals) и в итоге тебе придется таскать эти камни, прикладывать их друг к дружке и т.д. (тебе же не хочется мурыжить два камня по 10 тонн?). те кто умнее будут проверять например по левой грани (getName().equals) или по правой грани (getUid) ну и т.д. В этом случае тебе придется тягать камни гораздо меньше(что несомненно лучше), но все равно придется.

делай выводы кароч.

Все вышенаписанное является моим пониманием ситуации, если где то не прав, то с радостью узнаю где. лучше сейчас чем через npe
 
equals это как минимум обращение в таблицу виртуальных функций (а мы помним, что в Java методы все методы виртуальные), а затем ещё и ряд действий над его полями для вычисления hash. Поскольку логика сервера гарантирует, что у онлайн игрока только один Player, то лучше через ==, чему вообще обращаться по адресу в памяти, где лежат объекты, не нужно.
Спасибо за внятное объяснение.
 
ну смотри, у тебя есть допустим огромнейшая коробка(сервер). в которой лежат камни(игроки) по 10 тонн(вся дата игрока). допустим 50 камней.
на каждом камне выгравировано его уникальное имя(ссылка, адрес в памяти). теперь тебе тебе подсовывают еще один камушек, снова 10 тонн, и хотят узнать есть ли среди тех 50 аналог тому что тебе дали.

естественно ты как умный тупо найдешь камушек с таким же именем (проверка по ссылке), однако те кто сунули тебе этот камень хотят что бы ты проверил его по всем параметрам (Equals) и в итоге тебе придется таскать эти камни, прикладывать их друг к дружке и т.д. (тебе же не хочется мурыжить два камня по 10 тонн?). те кто умнее будут проверять например по левой грани (getName().equals) или по правой грани (getUid) ну и т.д. В этом случае тебе придется тягать камни гораздо меньше(что несомненно лучше), но все равно придется.

делай выводы кароч.

Все вышенаписанное является моим пониманием ситуации, если где то не прав, то с радостью узнаю где. лучше сейчас чем через npe
В принципе ты прав, насчёт "Оптимизации". Но вызов метода getName() или getUUID() не очень уж и затратно по времени.(Если количество игроков нормальное xD)
 
В принципе ты прав, насчёт "Оптимизации". Но вызов метода getName() или getUUID() не очень уж и затратно по времени.(Если количество игроков нормальное xD)
Вызов getName() и getUUID() пройет быстро да. А вот name.equals(name) пойдет проверять каждый байт, Bukkit.getServer().getPlayer(name), начнет собирать массив из игроков и потом уже проверять байты ника. Такие вещи лучше часто не дергать.
 
Назад
Верх