Два варианта добавления в List

t1h0n0ff

try {

    this.exclusions.add(exclusion);

} catch (NullPointerException ignored) {

    this.exclusions = new ArrayList<ExclusionJson>

    this.addExclusion(exclusion);

}

или
if (this.exclusions == null)

    this.exclusions = new ArrayList<ExclusionJson>



this.exclusions.add(exclusion);

При добавлении элементов 1 раз отловить Эксепшн и остальные разы слушать или каждый раз проверять на null? Что дорогостоящей?

apl13

А что, менее странных способов задержанной инициализации в джаве до сих пор не придумали?

t1h0n0ff

Например?

kokoc88

Третий вариант: сразу создать список и объявить поле final.

t1h0n0ff

Не.
Суть такая формируется json, если поле проинициализировано, то будет так [] отправлено на клиента, что не очень хорошо.
Вопрос в другом, как продуктивней?

apl13

В скале, если не ошибаюсь, список — абстрактный класс, у которого два наследника: Null и непустой список.
Сделай так.

Dasar

более быстрый первый вариант (с исключением но писать лучше так, как во втором варианте (с явной проверкой на null)

Marinavo_0507

рабоче-крестьянский вариант
при добавлении


this.not_empty = true;

при отправке


  if (this.not_empty) {

    // отправить this.exclusions

  } else {

    // отправить null

  }

lubanj

if (this.exclusions == null)
this.exclusions = new ArrayList<ExclusionJson>
где скобочки блиать?!

rotor89

1. Есть мнение, что плохо использовать исключения для неисключительных ситуаций (Bloch, Effective Java, Item 57).
2. Есть мнение, что плохо использовать null как вместо пустых коллекций (Bloch, Effective Java, Item 43 так и null'ы внутри коллекций (например, в Guava). При относительно сложной бизнес-логике null-checking становится проблемой.
3. У используемого тобой JSON-процессора может быть специальная опция, позволяющая обрабатывать такие случаи. Например, в Jackson можно делать @JsonInclude(Include.NON_EMPTY).

apl13

1. Есть мнение, что плохо использовать исключения для неисключительных ситуаций (Bloch, Effective Java, Item 57).
okay.jpg

yroslavasako

Что дорогостоящей?
Найди какой-нибудь фреймворк для микробенчмарков и потесть. Я для скалы так всегда делаю.

nikola1956

Думаю, правильнее всего так:


private List<ExclusionJson> exclusions  =  new ArrayList<ExclusionJson>

...

public void addExclusion(ExclusionJson exclusion){  exclusions.add(exclusion);  }

...

katrin2201

Производительность тут довольно спорынй вопрос.
Первый вариант будет сильно медленее второго, в тех случаях когда в поле null. К тому же, может некорректно работать, NPE, знаете ли, не только так, как задумал автор, можно словить.
Второй вариант может быть будет медленее первого, ибо типа лишний компэр, но извините вы этого на современных платформах ну вот совсем не заметите...

katrin2201

Рекомендую сначала прочитать айтем, а потом уже свои океи рисовать ;)
Тут кстати вроде недавно где-то пробегала ссылка, что какие бы то ни было эксепшены вообще зло, и там довольно разумные аргументы приводились... Так что...

katrin2201

Был у меня на собеседовании как-то человек, который производительность LinkedList'а бенчмаркил, чтобы получить очевидные выводы типа того, что дороже всего вставка в середину списка, а вставка в начало/конец дешевле всего.
Это так, к тому, что иногда быстрее все-таки сурсы побраузить.

yroslavasako

Это так, к тому, что иногда быстрее все-таки сурсы побраузить.
Для меня jvm - чёрный ящик. И учитывая, что реализации могут быть разными, я не стремлюсь его открыть и разбираться в содержимом. Вопрос о том, что лучше - условное выполнение или исключение относится скорее к реализации jvm и разнообразным оптимизациям. Поэтому всё-таки в данном случае сильно проще померить производительность бенчмарком.

katrin2201

Для меня jvm - чёрный ящик.
Это ж не очень хорошо, правда?

yroslavasako

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

katrin2201

Никто бы не хотел. Но реальность в том, что абстракции протекают, вне зависимости от того, хочется тебе или нет.

apl13

Тут кстати вроде недавно где-то пробегала ссылка, что какие бы то ни было эксепшены вообще зло
Разумеется, когда есть более высокоуровневые менее вербозные механизмы. :umnik:
Я, правда, читал по телевизору, что джава не тот случай. :(

yroslavasako

Никто бы не хотел. Но реальность в том, что абстракции протекают, вне зависимости от того, хочется тебе или нет.
абстракции протекают только если ты хочешь странного. То есть если ты хочешь от явы получить производительность плюсов. Пиши тогда на плюсах сразу. А если пишешь на яве - смирись с её проблемами. И выбирай её только в том случае, если даже учитывая все трудности, ява останется лучшим выбором

apl13

ява останется лучшим выбором
:ooo:

yroslavasako


ява останется лучшим выбором
:ooo:
А зачем тогда выбирать такую абстракцию, которую ты собираешься самолично сломать?

katrin2201

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

evgen5555

А сам рантайм объект на null не проверяет, чтобы бросить NPE?

Dasar

А сам рантайм объект на null не проверяет, чтобы бросить NPE?
не должен.
обычно это делается через наложение запрета на доступ к нулевой странице памяти, и обращение к ней вызывает "прерывание" процессора, которое уже и преобразуется в исключение

yroslavasako

То есть, я правильно понимаю, что если ты вдруг столкнешься с проблемой пефоманса первого варианта из исходного поста, то ты выберешь переписать все написанное на плюсы?
нет. Я выбиру усиление аппаратных средств.
А идеально - изначально точно оценить производительность java решения и сравнить выигрыш от дешевизны поддержки явы и дешивизны оборудования, необходимого, чтобы крутить си++ программмы. Что в совокупности дешевле - то и выбираем. Если в процессе выяснилось, что не все факторы были учтены и прогноз не оправдался - оштрафовать менеджера или самого себя и перепрогнозировать. С учётом варианта перехода на си или расширения аппаратуры. Если проблема со сроками - возьму технический долг и воспользуюсь j2c.

katrin2201

Чувствую себя как в том комиксе про "в интернете кто-то не прав", но не удержусь от последнего ответа тебе в этой теме.
Купить комп помощнее это, конечно, отличная отмаза, по мощности примерно такая же, как переписать все на плюсы.
Изначально точная оценка производительности проектируемого по в зависимости от языка реализации - это, конечно, круто. Очень интересно послушать про возможные методы оценки. У меня вот подозрение, что единственный способ такой оценки - это написать на обоих языках и сравнить.
Проблема еще в том, что даже если такой магический способ и существовал бы, то он бы, очевидно, учитывал способности конкретного программиста писать оптимальный код на том или ином языке.
И ты получил бы в итоге очевидную картину - программист, не понимающий на чем он пишет, вынужден писать на ассемблере и тратить человекогоды, чтобы уложиться в требования производительности. Когда нормальный программист пойдет и напишет на той же джаве за полгода.

katrin2201

В принципе не так уж и важно, там же еще нужно сконстрактить сам объект кидаемого исключения, в котором куча строк стектрейса, что даст 99% оверхеда.

Dasar

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

Maurog

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

Dasar

это где такой подход используют? JVM / CLR?
вроде как, везде

yroslavasako

У меня вот подозрение, что единственный способ такой оценки - это написать на обоих языках и сравнить.
Есть же большая сравнительная кодовая база. Всякие соревнования, где чей язык быстрее. И там вполне стабильное соотношение производительности показывают плюсы и ява

kill-still

А я вот что вам скажу товарищи! Нефиг ничего оптимизировать до запуска профилировщика.
З.Ы. 1ый вариант и не еби моск.

evgen5555

Да это-то понятно, просто интересно как рантайм выбрасывает npe без проверки собственно объекта.

evolet


В принципе не так уж и важно, там же еще нужно сконстрактить сам объект кидаемого исключения, в котором куча строк стектрейса, что даст 99% оверхеда.
в целом, это не важно, если рассматривается сценарий, когда при работе одно нулевое значение приходится на тысячи ненулевых
я с тобой согласан, что это неважно, если у нас сценарий со списками с типичной длиной 1000+ элементов, да, в таком случае жалкие тысячи тактов на исключение это будет капля в море, согласен :)

Dasar

если у нас сценарий со списками с типичной длиной 1000+ элементов
корректнее "1000+ обращений на один список", чем "1000+ элементов".

evolet

честно говоря не знаю, что именно внутри ArrayList, но если это в итоге классический список с указателями, то скорее всего в списке на 1000+ обращений тоже будет все не очень хорошо, т.к. в таких случаях надо думать не о уменьшении кол-ва сравнений, а о лояльности к кэшу

Dasar

ты уже куда-то в дебри
есть две конструкции:


  if (zzz == null)

     zzz = new Zzz(...);

  zzz.bla-bla;

vs


try

{

   zzz.bla-bla;

}

catch (NullException exc)

{

   if (zzz == null)

     zzz = new Zzz(...);

  zzz.bla-bla;

}

вторая конструкция будет быстрее, если данный участок кода вызывается много чаще при zzz не равном null-ю.
или другими словами, когда есть сотни-тысячи вызовов bla-bla на один экземпляр Zzz

kokoc88

вторая конструкция будет быстрее, если данный участок кода вызывается много чаще при zzz не равном null-ю.
Блядь, 99.99% программистов реализуют алгоритм Дейкстры через динамический массив, а вы тут уже почти диссертацию написали на тему одного if?

Dasar

в данном случае, тема скорее про то, как аккуратнее оценивать производительность кода

evolet

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

evolet

а 99.99% населения вобще не смогут реализовать алгоритм Дейкстры :)

Dasar

тут надо учитывать дополнительный код, который компиялтор неявно вставляет чтобы обеспечить необходиму семантику в случае исключения
afaik, добавляется один push в ветке, когда исключение не произошло; и много-много кода (включая неявный когда исключение произошло.

schipuchka1

Для меня jvm - чёрный ящик. И учитывая, что реализации могут быть разными, я не стремлюсь его открыть и разбираться в содержимом. Вопрос о том, что лучше - условное выполнение или исключение относится скорее к реализации jvm и разнообразным оптимизациям. Поэтому всё-таки в данном случае сильно проще померить производительность бенчмарком.
эта часть JVM описывается
Оставить комментарий
Имя или ник:
Комментарий: