Советы по оптимизации кода на Java: как не наступать на грабли

[Mingun]

Возможно, в stringAppend компилятор сразу формирует готовую строку и просто возвращает готовый результат. Было бы странно, если такая очевидная оптимизация не делалась бы.

[mspain]

Статью надо было назвать «Открытия java-junior в время испытательного срока»

[nonnenmacher]

Если честно, маловато по теме. Можно, например, добавить, что при проверках if нужно наименее затратные проверки ставить вперёд и т.д.

[tsvetkovpa]

Скорее нужно ставить вперед те, которые, если сработают, с наибольшей вероятностью сделают последующие ненужными

[asympro]

>Если у кого-нибудь есть версии, почему так происходит – поделитесь пожалуйста в комментариях.

У меня строго диаметральная ситуация:

Benchmark Mode Cnt Score Error Units
stringAppend thrpt 6 26,659 0,236 ops/us
stringAppendBuilder thrpt 6 6,941 0,119 ops/us

[Mobilnik]

Уважаемые ph_piter!

Если соберетесь действительно издавать перевод книги, пожалуйста, переводите термины аккуратнее, а названия классов не переводите вовсе. Ни разу не сталкивался с великим и могучим «ПОСТРОИТЕЛЕМ СТРОК» :), потребовалось несколько секунд, чтобы понять, что это за зверь.

А так буду рад видеть вашу книгу.
Спасибо за статью.

[dimkrayan]

плюс, стримы желательно вообще не переводить. Поток — очень не однозначный термин.

[Throwable]

Неужели у кого-то реально проект из-за того, что он неправильно пользовал StringBuilder или stream вместо for? В 95% случаев всегда тормозит база данных, причем в половине случаев решение не такое тривиальное, как просто переписать запросы: требуются серьезные архитектурные модификации, использование кешей и т.д. Кроме того, на продакшне ситуация может сильно отличаться от тестового бенча, поэтому всякие профайлеры тут не помогут. Поэтому совет один — используйте лайв мониторинг и фреймворки типа Metrics, пишите понятный код и не сильно забивайте голову всей этой фигней по поводу stream/for, StringBuilder, etc...

[mspain]

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

[vedenin1980]

у кого-то реально проект из-за того, что он неправильно пользовал StringBuilder или stream вместо for

У меня было. Просто надо понимать, что если у вас обычный не сильнозагруженный сайт — то вы правы, если что-то и надо оптимизировать, то кривую работу с базой данных, сетью и т.п. Если у вас что-то вроде BigData, где каждую секунду надо переваривать миллиарды строк, как-то их группировать и обрабатывать, то любой чих в коде вроде Integer вместо int разом превращается в лишний сервер за десяток тысяч $.

пишите понятный код и не сильно забивайте голову всей этой фигней по поводу stream/for, StringBuilder, etc...

Проекты все-таки бывают разные, представьте, что разработчики Hadoop или Apache Spark не будут забивать голову такой фигней?

[panchmp]

тут приведены азы для юниора, а не разработчика Hadoop или Apache Spark

[vedenin1980]

Любой юниор может рано или поздно оказаться в компании аналогичной Hadoop или Apache Spark. Просто надо понимать, что есть проекты, где производительность вообще не важна, а есть где супер важна и нужно уметь писать код в любом случае, иначе просто не пройдешь собеседования.

[Throwable]

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

Поэтому если у вас BigData и вам приходится перелопачивать мегатонны, то скорей всего вы плохо используете данную технологию: там как правило уже есть встроенные оптимизированные средства перелопачивания ввиде Hive, Spark или KSQL. В итоге бизнес работает с уже перелопаченной выжимкой, где особая оптимизация не нужна.

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

[tmn4jq]

Добрый вечер, коллеги.

Вранье! Издатель программисту не коллега!

А если серьезно, то перевод весьма хороший и качественный ровно до тех пор, пока речь не заходит о конкретных терминах. Поток, журналирование и, самая жесть, ПОСТРОИТЕЛЬ СТРОК – это просто беда. Как уже отметили, «поток» понятие широкое – это может быть поток выполнения, то есть, «thread». Это также может быть и тот stream, о котором на самом деле идет речь. Журналирование еще можно понять, но, опять-таки, никто никогда не говорит это слово, тут привычнее использовать «логгинг» или хотя бы «логгирование». Про построитель строк уже упомянули. Это имя класса, StringBuilder – его ни в коем случае нельзя переводить.

Обидно, что сам-то перевод с английского на русский сделан качественно, но заставляет страдать то, как вы переводите профессиональные термины. Это та причина, по которой я дважды подумаю, а не почитать ли мне лучше оригинал, прежде чем покупать книгу в переводе.

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