Конференцiя React fwdays. Приєднуйся безкоштовно або бери квитки поки regular | 27 березня
×Закрыть

Какая гадость, эта ваша Java!

Короткая версия: bit.ly/TlJ5ZV
Более полная версия: bit.ly/UDEmDR
.
UPD.
Интересная ссылка про производительность исключение (от Андрей Донской): bit.ly/1sggh4C

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Що винятки є взагалі дорогим механізмом — це не новина і написане у всіх підручниках. А от наскільки вони дорогі у деякій мові/реалізації — то вже конкретніше. Як на мене, було б корисніше побачити порівняння ціни генерації винятка у різних мовах сходного типу (Java, C#...) та близького (C++).
А дурна оптимізація... що поробиш коли >90% кодерів це індуси...

Як на мене, було б корисніше побачити порівняння ціни генерації винятка у різних мовах сходного типу (Java, C#...) та близького (C++).
Не “полезнее”, а забавнее :)
.
Вот вбросик про “лямбды” и их производительность в разных языках bit.ly/1pwUOic
Как по мне автор что-то не так измерял (или я не так прочитал), бо получется что Scala — УГ.

Джаву — вижу, гадость — не вижу. Вывод: Ошибка в названии темы.

гадость — не вижу.
#define true false // happy debugging losers
Джаву — вижу, гадость — не вижу. Вывод: Ошибка в названии темы.
Техническая тема на ДОУ, 85 комментариев и 3998 просмотров.
Вывод: Ошибка в выводе :)

Тема цікава, але місце не правильне. Замість конструктиву якась муть...(в стилі доу ;) )
Питання чому і для чого можна така опція можна задати Sergey Kuksenko або Aleksey Shipilёv. (контакти можна в неті нарити).
ПС. Доречі в україні нема, де поговорити про Java. Доречі к-сть java dev в нас одна з найбільших.

Питання чому і для чого можна така опція можна задати Sergey Kuksenko або Aleksey Shipilёv. (контакти можна в неті нарити).

Богдан, ну с Вашей стороны, конечно же, конструктива куда больше, чем в этом топике можно найти... У меня тогда вопрос к Вам, а почему Sergey Kuksenko або Aleksey Shipilёv а не James Gosling або Joshua Bloch? Их контакты тоже можно нарыть в интернете.

Кроме того по Вашему совету в итоге получится диалог 2x людей в стиле вопрос — ответ, а в нашем случае можно наблюдать дискуссии с 2+, что помогает лучше прощупать почву под ногами. Или Вы всеже настаивайте, что Sergey Kuksenko/Aleksey Shipilёv и может еще кто-то там лучше думают, чем мы?

Шипилев, Ирина, не просто думает, он делает больше чем 99% обитателей dou.

Шипилев, Ирина, не просто думает, он делает больше чем 99% обитателей dou.

Андрей, не спишите приписывать мне того, чего нет, не тратьте попусту силы, время и место на DOU. Лучше попытайтесь раскрыть тему топика лучше. Давайте может подискутируем в разрезе технических вопросов. Например мой вопрос Вам остался без ответа: dou.ua/...c/10136/#490040

Или Вы любитель потролить?

Я, Ирина, на dou придерживаюсь двух правил:
— не кормлю эльфов и троллей
— не трачу время на бесконечные дискуссии необъятных размеров

Если кому-то это не нравится, или мои комментарии разжевывать нужно — это не моя проблема.

Если кому-то это не нравится, или мои комментарии разжевывать нужно — это не моя проблема.

Жаль, потому что мне интересно с Вами общаться, Андрей. Я уверена в том, что от Вас узнала бы что-то новое или переосмыслила старое.

Якщо б ви відвідали останні Java івенти ви б знали чому саме вони!(Це одне з того чим вони займаються на Ораклі)

Непотрібно розводити срач!

PS. Pls don’t feed troll!

какой ужас,срочно же пойду переписывать свой рандомный генератор на экепшенах и откатыватся на 5 версию жвм.

Через багато-пребагато років довелося трошки пописати на джаві (зараз робота уся на C++/COM+ та C#). Писав плагін під Дженкінс і почали лізти якісь неймовірні проблеми просто через що я почав робити нотатки. Ось це нижче за один день, потім махнув рукою і просто мовчки боровся. Також хочу зауважити що все нижченаписане є нотатками людини якій треба було швиденько написати на джаві невеличку штучку і одразу забути про все це, отже вивчення осно та принципів покладених у джаву/жвм/дженкінс/екліпс/you name it абсолютно було непотрібно.
-----------------------
1. Встановлення і конфігурування
a. JDK вдалося встановити без особливих складнощів з сайту Oracle, єдине що треба було уточнити який саме вид мені потрібен: SE, EE чи ще там щось. Кросплатформеність така кросплатформеність, ага. А як же «написане одного разу запускається будь-де»?
b. Maven (білд-система) нагадали про часи DOS: спочатку викачай zip-файл, розпакуй у правильний каталог і додай ось ці і ось ці змінні оточення. Про інсталятори чи хоча б скрипти я так розумію розробники не чули?
c. З Eclipse (IDE) та сама історія що і з Мевен.
2. Початок роботи
a. Відкрити проект в Екліпсі... Стривайте, а чого цей пункт меню не доступний. Добре, спробуємо просто файл проекту відкрити — відкривається як xml. Добре, шукаємо в bing — ага, треба імпортувати проект і пройти через якісь кроки. Нахєра?! Чому б не дати можливість просто відкрити проект?
b. Пробуємо білдити... Хм, а такого пункта меню навіть нема. Проте Екліпс показує сотні помилок пов’язаних з тим що нема певних пакетів на машині. Є функція «знайти і встановити пакети», але вона не працює (тупо нічого не робить). Рішення з інтернету — відредагувати файл налаштувань Maven вручну додавши в нього посилання на необхідні проекти і запустити білд з командного рядка. В процесі 10 хвилинного білда для манюсенького проекту витягнуто з інтернету сотні пакетів на 92 Мб — звісно ж включити їх в той же Мевен чи Екліпс чи ЖДК не можна було, ну та ок, вже і так ясно що Windows way тут не вийде.
c. Повертаємося в Екліпс — ті ж самі помилки про недоступність пакетів нікуди не ділися. Як же примусити Екліпс побачити пакети які вже встановлені для Мевен? Виявляється для цього є плагін для Екліпса. А встановлювати плагіни в найкращих традиція психічних треба за допомогою одного з підпунктів меню Help. Шукаємо щось для Мавена і не знаходимо потрібного. Причина в тому що хоча ми і встановили стандартний ЖДК (він нам і потрібен) Екліпс все одно треба брати для Ентерпрайз ЖДК. Що ж, повторюємо крок 1.c та 2.a.
3. Нарешті запускаю Дженкінс.
a. Перший запуск — і в плагінах якесь сміття, нема мого плагіна. Специ кажуть що «таке буває при першому запуску». Перестартовую — мій плагін у списку.
b. Пробую створити білд джоб — креш. В чому ж річ? Та просто Дженкінс не працює з ЖДК 8, треба ставити 7, і це виявляється давно відома проблема. Фейспалм... Зносимо Джаву 8, ставимо Джаву 7. Нарешті запустилося.
4. Дрібниці
a. Нема var! Навіть в С++ вже є автовиведення типу (auto), а тут треба кожного разу його писати вручну, кам’яна доба якась
b. ...
-----------------------------------
Ось таке за одни день.
Я чайник?

Про інсталятори чи хоча б скрипти я так розумію розробники не чули?
brew install maven
a. Нема var! Навіть в С++ вже є автовиведення типу (auto), а тут треба кожного разу його писати вручну, кам’яна доба якась
В эклипсе нет рефакторинга “сынести переменную”? Это печально, поставьте ИДЕА.
.
Я чайник?
Нет, скорее всего вы просто виндузятник :)
А если серьездно, то все описанные вами проблемы появляются тогда когда вместо того чтобы прочитать доку, начинаешь изучать малознакомую технологию методом тыка. И это ожидаемый результат.
Кстати, про прочтение. Вы ссылки читали или наплодили свой опус на основе заголовка?
Кстати, про прочтение. Вы ссылки читали или наплодили свой опус на основе заголовка?
В основному так, хоча статтю почитав. Нюанси з ексепшионами для мене якось дуже специфічні.
В эклипсе нет рефакторинга «сынести переменную»? Это печально, поставьте ИДЕА.
есть,
Я чайник?
нi
сбiлдити новий проект з купою залежностей бува досить складно, особливо якщо його рукожoпi люди робили. Еклiпса досить крива, в IDEA якось зручнiше та скорiше все робиться.

Ну не знаю... Стільки букв про те, як автор розповідає про тули на яких має писати... І ніфіга про них не знає... . По простому Java ламер!
Java не сілвер буліт, але краще не треба писати про, те в чому ніфіга не розумієш!

Абсолютно з вами згоден, я і є джава-ламер, нічого образливого в цьому не бачу. Просто деякі речі мені здалися ненормально переускладненими та відсталими, тому і згадав.
А чому на джаві? Ну так для дженкінса ж без геморою ні на чому іншому не напишеш? Чому Екліпс? Так у джавістів у кожного своя ІДЕ, що більшість людей порадила те і взяв.
І так, мені не треба «знати» ті всі тули і технології, мені треба щоб увесь процес працював. І ось те що я робив це просто додавання відсутнього компоненту для автоматизації процесу.

Якщо ви маєте бажання дізнатись чому саме так, а не інакше — створіть новий топік.
І думаю вам там дадуть відповідь. В цьому топуку Ваш комент є просто флудом і ні прощо.

PS. Pls don’t feed troll!

b. Maven (білд-система) нагадали про часи DOS: спочатку викачай zip-файл, розпакуй у правильний каталог і додай ось ці і ось ці змінні оточення. Про інсталятори чи хоча б скрипти я так розумію розробники не чули?

Поверьте!!! Я сам пишу на си-шарпе, уже 7 лет. Дочь офицера. Просто поверьте, — у нас не все так однозначно... Не везде есть инсталлеры.

Копировать файлики и прописывать environment variables для меня лично более предпочтительно чем инсталлеры. По крайней мере чётко видно что куда ставится. + в случае поломки/апгрейда/реинсталла проще манипулировать папочкой чем выковыривать неудачно установленный инсталлер.

Я чайник?
Я некоторое время писал на джаве 7, первая неделя — схожие проблемы. Надо втянуться. Потом — всё понятно и логично(я только к эклипсу не привык, поставил idea).
кам’яна доба якась
Зносимо Джаву 8,
8-й джаве прибавили няшности, ставьте обратно :)

Попробовали бы билдить в IDEA — не знали бы проблем, там родная интеграция с мавеном и нет такого бреда как поставить 1-2 плагина шоп только мавен заработал. Большая часть испытываемах вами проблем — глюки Eclipse, этого недоинструмента цвета детской неожиданности. Ну и Jenkins — не фонтан, потому что некоммерческий, там тоже бывают бока.

Ок, буду знати на майбутнє. Але схоже у джавістів екліпс це що релегійне — спроряться за неї аж до слини з рота.

Эклипсом пользуются только староверы

Не обобщайте, за Eclipse бьются разве что индусы, потому что 1xIDEA = 2 их месячные зарплаты. Также джуны и просто неадекваты тоже восхваляют.

за Eclipse бьются разве что индусы
Android Studio забила очередной гвоздь в гроб эклипса, но в то же время учитывая бесплатность студии индусы продолжают пользоваться эклипсом, видимо им нравятся страдания

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

у нас есть один два чувака которые на эклипсе. оба англичане сильно овер 40, так что не так все однозначно

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

все это работает намного лучше В ЕКЛИПСЕ
с другой стороны, ИДЕЯ лучше работает с HTML, CSS, JSP, XML
потому у меня не редкость, когда один проект у меня открыт сразу в двух средах

я так поняв на гуглі почали банити? а то фиходе топік в стилі — жаліюся на те що ніц не розумію, не знаю, і топу ця ваша джава бяка

Первый технический topic на dou за долгое-долгое время. Ура товарищи! (реально круто)

а що, хіба не можна просто НЕ використовувати exception для control-flow? чи це занадто нудно?

а що, хіба не можна просто НЕ використовувати exception для control-flow? чи це занадто нудно?

Вопрос интересный. Есть некотороя статья, на которую любят ссылаться на различных форумах: c2.com/...sForFlowControl, мол по результату прочтения этой статьи можно сказать, что использование exception’ов для контроля потока выполнения программы — antipattern. Но мне кажеться, что примеры из этой статьи несколько странны, и по ним тяжело мне сделать такой вывод.

Exception’ы, как мне кажется, дают возможность понять метод лучше по его описанию (в случае с Java добавить в JavaDoc описание частного случая ошибки), а именно что будет в результате нормального его завершения или ошибки, в результате чего мы имеем два типа завершения, один — при нормальном завершении, а второй — при ошибки. Жизнь без exception’ов мне кажется сложной, так как нам прийдется инкапсулировать знание об ошибке в возвращаемый объект и проверять его при помощи других операторов, например, if/else или switch/case, что, как мне кажется, ничем не лучше try/catch.

При этом нужно либо знать об этой оптимизиции
именно.

гадость в том что сейчас любые промышленные компиляторы-интерпретаторы имеют кучу флагов, с неочевидным воздействием. посмотрите список флагов компилятора C++ или загляните в php.ini
по эксепшенам в том же С++ помнится вообще есть несколько реализаций, вплоть до их несовместимости при линковке.

вторая гадость что не всегда они указаны все в одном месте, а разок точно нужно прочесть эту простыню просто как художественную книгу.
например OmitStackTraceInFastThrow
в списке Java HotSpot VM Options нет
а в бложике «Stas’s blog» The most complete list of -XX options for Java JVM есть.

кстати, на собеседовании мидла и выше вполне можно гонять и по ним, типа
а что делает включенный по умолчанию ResizePLAB?

кстати, на собеседовании мидла и выше вполне можно гонять и по ним, типа
а что делает включенный по умолчанию ResizePLAB?

Ну, это уже просто снобизм.

Я, например, только что впервые в жизни прочитал про «ResizePLAB». Как-то без этого вполне успешно работал всю дорогу.

На собеседовании даже архитектора не стоит на таких вещах гонять. Причина проста, как голая задница: люди этого не запоминают, а читают ОДИН раз, прописывают ОДИН раз, и забывают до следующего раза.

Например я тебе не смогу ответить даже по собственному коду, написанному вчера. А есть такие места, где я не смогут ответить даже через полчаса после написания, и приходится каждый раз читать коменты.

Так и с оптимизацией. Какашка не в том, что это нужно помнить. А в том, что нет толковой документации в одном месте, она разбросана по разным бложикам. Хотя по-хорошему я должен просто написать man java и получить счастье. Равно как и иметь сэмпл ини-файла с прописанными флагами, которые мне нужно просто раскомментить.

Вот например упомянутый тобой «ResizePLAB» — в поиске гуглом первая же [и единственная] русскоязычная ссылка ведёт... прямо сюда, на твой пост!!! Понимаешь теперь, насколько идиотизмом будет спрашивать это на собеседовании? Ты ведь только сам себя нанять сможешь! Я очень надеюсь, что ты не будешь проводить собеседований никогда.

в целом согласен. я ж так, пошутил типа :)

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

нагуглил вот например Lock Coarsening, Biased Locking, Escape Analysis and others

согласитесь, понимание поддержки в JVM и работы железа для многопоточных приложений — весьма полезно в модных hi-load проектах.

Так и с оптимизацией. Какашка не в том, что это нужно помнить. А в том, что нет толковой документации в одном месте, она разбросана по разным бложикам.
то что понято — запоминается надольше чем то что зазубрено.

а вот как раз трудолюбие по собиранию в бложиках и разрозненных источниках — один из показателей проактивного профессионализма.

слышал что в западных компаниях блог в котором такой собиратель публикует собранное — очень засчитывается в плюс.
по крайней мере индийцы в сообществах в G+ рекламируют свои блоги с стопицотым копипастом работы StringBuilder до оскомины.

По правде сказать, BiasedLocking я и сам не очень-то понял. Понятно, что если его врубить на JVM, использующей какой-то хорошо вылизанный фреймворк на коротких блокировках — это даст скорости. Но в прикладном кодировании короткие блокировки сложны, предпочитают использовать длинные и даже многоуровневую вложенность.
А если иметь дело с типовой ReadWriteLock, которая действительно имеет короткую блокировку и оптимизацию — эта опция даст какой-то разгруз? Или же там изначально заложен вылизанный unsafe-код?

не так.

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

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

думаю что для программиста скажем на Prolog, Haskell — этих знаний не требуется, эти ЯП очень удалены от железа, чтобы для их использования была польза от знания что такое стек.

а джавист, в hi-load?

вот сколько тем только на доу было о том — а чё лучше один запрос — один поток, или тьма запросов — один поток и опрашивает? и как мерять, что в каком проект будет лучше?
и какие средства, подходы и почему есть в мире Java? и как их правильно пользовать, а как — неправильно?

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

соответственно можно с них, с ключиков этих и начать собеседование. с десерта так сказать, к которому чел придет от вопросов «один запрос — один поток, или ...»

Хай-лоад хай-лоаду рознь. Бывают случаи, когда приходится заниматься совсем не ключиками JVM, а реализовывать собственно алгоритмы. К примеру, многозвенная система а-ля доминошки. Когда стоит упасть одному звену — и весь конвейр начинает неподецки жрать оперативку и задействовать резервы. Тут уж волей-неволей задумаешься об оптимизациях типа синглтон-исключений.

А если часть этого карточного домика — удалённый сервис на другом конце планеты, который с надёжностью далеко не 100%, и по нагрузке «не бей лежачего»? Здесь явно не станешь ждать, пока JVM сама «допетрит» что в неё срут исключениями. Тут приходить брать каждое и анализировать. Притом что в потоке этого дерьма нужно выловить отдельно типичные исключения, отдельно редкие, и ещё найти те которых никогда не было [потому как код меняется].

Так что могу заверить, high-load — это не java. Это отдельная наука, и она справедлива для любого языка — ведь процессы по сути те же. А касательно типичного сокращения потребления памяти или циклов GC — смею заверить, что железобетонное решение в виде добавить гектар-другой памяти процессу обходиться в сотни раз дешевле оптимизации кода. Уж очень часто програмисты забывают сравнить цену памяти с ценой своего времени.

А касательно типичного сокращения потребления памяти или циклов GC — смею заверить, что железобетонное решение в виде добавить гектар-другой памяти процессу обходиться в сотни раз дешевле оптимизации кода. Уж очень часто програмисты забывают сравнить цену памяти с ценой своего времени.

На эту тему есть интересная статья:
Hardware is Cheap, Programmers are Expensive.

UPD: Автор статьи рекомендует использовать следующий подход при решении проблем с оптимизацией:

  • Throw cheap, faster hardware at the performance problem.
  • If the application now meets your performance goals, stop.
  • Benchmark your code to identify specifically where the performance problems are.
  • Analyze and optimize the areas that you identified in the previous step.
  • If the application now meets your performance goals, stop.
  • Go to step 1.
а реализовывать собственно алгоритмы.
какие именно?
вот например для алгоритма конкарент хэшмапы — достаточно знать только прикладную математику?
откройте код в JRE — и посмотрите. и объясните его работу только чистой математикой.
Когда стоит упасть одному звену — и весь конвейр начинает неподецки жрать оперативку и задействовать резервы.
да, и такие алгоритмы нужны, и знания железа для их создания — не нужны.

что вы хотите показать этим примером?

Так что могу заверить, high-load — это не java.
приведенными примерами — НЕ заверили.

The LMAX Architecture (Disruptor) — алгоритм или нет?

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

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

хотя примерами, если вы еще не знаете, что странно учитывая проф стаж, вообще НИЧЕГО нельзя доказать.
я по крайней мере и не думал утверждать что ТОЛЬКО мои примеры составляют ВСЕ программирование.
особенно смешно что я как раз чаще говорю — забей на перфоманс, потом, вернешься. может быть. если понадобится.
но никогда не говорил что так нужно делать — ВСЕГДА, безусловно.

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

хотя не, с функциональщиками все же инетерсно и полезно. математики потому что.

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

Это зря. Мне интересно и познавательно читать Ваши коментарии, Серёжа, ровно как и многих других. И я думаю, что я здесь не одна такая.

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

не, с функциональщиками интереснее. у них, нередко упоротых математиков — «а вот я знаю случай!» в качестве аргумента не используется и не принимается.
а если хотят возразить обобщению, которое считают неверным, то — «огласите граничные условия применения пжлст»

Эмм... Честно говоря (только не обижайтесь) мне Ваши топики о программировании читать сильно интереснее, чем политические.
Может потому, что сам вырос из ассемблера и С, может потому что нахожу в них новую и полезную для себя информацию, в отличие от политики, сложно сказать.
Так что мне кажется, что Вы себя недооцениваете в этом плане. )

Честно говоря (только не обижайтесь) мне Ваши топики о программировании
там хоть лайкают мои посты.
а у моих программерских — лайкают оппонентов. причем, далеко, ИМХО, не лучшие посты оппонирующих.

роль д’Артаньяна не по мне.

там хоть лайкают мои посты.
забавный у вас критерий. Если подумать, то и оппонента у вас нет. Есть вселенское зло, не удостаивающее вас ответом. А вы как Дон-Кихот гордо боретесь с ветряными мельницами. Поливаете всех грязью, генерируете флейм и таким образом получаете лайки, не прикладывая особых усилий. Это и есть ваша цель?

Ну уж не знаю, кто за чем на DOU идет (статистики такой нет, либо я что-то пропустила...), но я думаю есть и те, кто ищет не д’Артаньяна, а сильного технаря, с которым интересно обсудить технические темы, к которому я Вас отношу.

P.S. Если вопрос в лайках, то я могу почитить немножко на DOU, чтобы пропудить Ваш интерес, Серёжа, к техническим дискусиям. Например заведу себе пару тройку учеток на DOU, и буду лайкать Ваши коментарии ;-)

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

уже говорил — всяк ресурс ценен уникальностью. уникальность доу вовсе не в технических темах. как по мне.

уникальность доу вовсе не в технических темах. как по мне.

Как мне кажется, Серёжа, уникальность DOU в том, что этот ресурс сумел собрать много отличных технических специалистов, как Вы. А как — это уже не тема этого топика, но скажу, что не последним тут была и роль ребят из команды DOU.

хорошая идея. я напишу скрипт для этого. создадим пулл аккаунтов и пулл прокси серверов, будем лайкать

Артем, спасибо, идея интересная, но применение ее нет, так как это чистой воды тролинг. Давайте вы попробуйте написать такое приложение и выложите ссылку на исходники, я думаю, что этому произведению можно будет другое назначение придумать, более полезное. Ну правда при условии, если Вы научите свое приложение разгадывать капчи без индусов.

хай лоад это в первую очередь инфраструктура. А тем кто сразу O считать начинает и ключики надрачивать — надо с вертушки в щщи проряжать

В ваших словая есть просвет смысла, но все равно это фраза в стиле «Буду есть ложкой, потому что она лучше вилки. Нужно основать Церковь Ложки». Нельзя ли пользоваться всеми средствами которые помогают и не пользоваться средствами которые не помогают?

я утрирую.
но те эпичные факапы что я припоминаю почти всегда были или архетектурные или из за не желания отлаживать всякие экстремальные сценарии файловеров и тому подобное.
Если у тебя какая нибуть критичная очередь или база постоянно косячат и тормозят — обычно на O можно наплевать с высокой колокольни. Все загнется еще до того как пригодится алгоритмическая оптимизация.
средства надо использовать все, но публика на jvm имеет тендерцию создавать себе уютный мирок и оптимизировать до усрачки код при дефолтных настройках mysql я

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

Шикарная фраза

А касательно типичного сокращения потребления памяти или циклов GC — смею заверить, что железобетонное решение в виде добавить гектар-другой памяти процессу обходиться в сотни раз дешевле оптимизации кода.

Но не нужно забывать что в Computer Science иногда смена алгоритма меняет все на порядки. Особенно если с удивлением обнаружить какой-то O(n^3) алгоритм где-то в закоулке кода и просто заменить его на что-то вменяемое. А когда его писали кстати, данных много не было и выбор был адекватный с точки зрения баланса эффективности и простоты реализации. Иногда действительно в некоторых закоулках batch задач можно что-то поменять и превратить 5 часов в 10 секунд

Но всё это обычно ловится на первом рефакторе. А там где изначально тратится время на вылизывание кода под нагрузку — как правило выигрыш минимальный, если вообще есть.

Типичный случай — строки. Как показывает практика, оптимизировать нужно «простые и элегантные» куски кода, где кто-то догадался сцеплять строку в цикле. Или через задницу нарисовал регулярное выражение.
А там где кода сравнительно много, но линейного, без абстракций и блокировок — там оптимизация не требуется, ибо такие операции выполняются миллиардами в секунду. «Красивая» оптимизация может в итоге сэкономить секунду в год. А потратить на свою отладку неделю. А вс потому, что интуиция подсказывает оптимизировать большие участки кода. Хотя на самом деле дьявол кроется в самых мелочах.

Простейший случай для java: собирать большие обьекты по одному в new ArrayList(). Оптимизация заключается в создании массива готового размера. Но кто ж её делает? Ещё более круто, когда возьмут LinkedList или Deque, а потом хотят перебирать циклом типа for (element:List). В коде всё элегантно. А в байт-коде с удивлением обнаружим toArray, который весьма затратен для связанного списка. И эти ситуации типичны — оптимизация очень часто достигается уходом от абстракций, и чёткой записью в коде откуда брать и что делать.

Тот же самый разбор регулярных выражений. Зачастую надёжнее пройтись «руками» и точно знать что проход будет один, чем потом удивляться что документ в 100 000 символов обрабатывается несколько минут вместо положенных микросекунд.

Чем тяжелее моральные травмы у автора, тем сильнее его интересуют битовые сдвиги и такие вещи:

кстати, на собеседовании мидла и выше вполне можно гонять и по ним, типа
а что делает включенный по умолчанию ResizePLAB?
Есть смысл спрашивать не больше, чем в сертификации от Oracle, например по servlet/jsp и прочем веб компонентам, а также вебконтейнерам не больше чем здесь (вкладка «Exam Topics»):
education.oracle.com/...p_org_id=&lang=

от проектов на самом деле зависит.

тот же jsp — та на кой по нем спрашивать если в компании ни одного проекта на нем нет, и не будет, а все на REST и ExtJS, а в планах еще и на Vert.x перейти.

Спрашивать что-то слишком узкоспециализированное (костыль для конкретного случая) как минимум — странно. По поводу JSP я просто привел пример на мой взгляд адекватного подхода к вопросам собеседования по технологическому стеку = целостный подход и базовые знания, а тонкости и фишки человек постигнет на проекте, если чуваки хоть слегка помогут. По поводу REST/JS А если человек допустим всю жизнь писал на SOAP никогда не работал с какой-то супер-популярной js-либой типо Angular, а писал на jQuery/Backbone — его тоже низзя брать?

брать можно любого толкового.

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

в данном случае есть две концепции:
1. UI генерится на сервере
2. UI создается одними средствами — сервер только выдает по запросу из этого UI, и разрабатывается другими средствами

и тогда видно, что родственными являются:
1. JSP (Struts), JSF
2. REST, SOAP — сервер, UI — ExtJS, Angular, jQuery/Backbone

в жизни конечно встречал что и часть кода для ExtJS генерится.

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

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

Лучше молчать і прослить ідіотом, чєм откріть рот і развєять всє сомнєнія

Если бы Java могла сказать всё, что думает о программистах под неё...
появился бы отдельный матерный диалект исключений. Большинство из которых сводилось бы к синглтонам RTFM и RBBG.

А самой JVM не помешала бы опция -DisableStandardInterface

Спасибо за опцию: -XX:-OmitStackTraceInFastThrow
Ну мы как-бы в курсе, шоп JVM нормально работала, ее надо тюнинговать и бегать с бубном, так шо вы «омерику» не открыли.

шоп JVM нормально работала, ее надо тюнинговать и бегать с бубном
Так не держите все в себе. Расскажите про те странности с которыми вам приходилось сталкиваться. Цель же не потрандеть, а узнать/поделится чем-то полезным.

Самое интересное начнется, когда автора сей «оптимизации» и след на проекте простынет, а его коллеги включат библиотку, активно использующую exceptions для своей внутренней кухни. И будут N дней ломать голову, чего ж все приложение так по производительности просело, с якобы такой быстрой и красивой новой библиотекой (для парсинга JSON, к примеру). И потом, найдя эту «оптимизацию», еще не один вечер будут поминать автора незлым тихим...

За что ж Вы коллег своих по цеху так не любите...

P.S. grep / awk в помощь для поиска первого не оптимизированного JVM exception с полным стэк трейсом.

Прежде чем делать такие громкие заявления не мешало бы пройтись профайлером по приложению и оценить реальные узкие места: многократные коннекты к БД, операции над hibernate-entity в циклах с flush-ом, бешеные циклы многократной вложенности, конкатенация String-ов в миллионных экземплярах. Вот здесь проседает производительность, а не в несчастных exception-ах.

Как раз этим они и будут заниматься первые N — 1 дней.

Искать виноватых в своих неудачах — удел непрофессионалов. До подключения библиотеки все было ОК, но вот ушел чувак и надо подключить, а то «не труъ», стало херово работать — обвиним его. Так рассуждают непрофессионалы.

Повторяю еще раз для любителей передвигать стулья на Титанике: для оптимизации производительности следует фокусировать усилия на реальных узких местах и обращать внимание на все подключаемые библиотеки, в идеале делать профайлинг до и после. Если просадка и будет, то незначительная.

включат библиотку, активно использующую exceptions для своей внутренней кухни. И будут N дней ломать голову, чего ж все приложение так по производительности просело
лол просто лол.
Если у вас производительность упрется в «выброс исключений» (всякие ХФТ и тд), то:
1) Вы не будете использовать библиотеку которая активно работает с исключениями. К слову, «быстро» и «на исключениях» как-то не сходится.
2) На проекте будет довольно хорошо описано в документации, почему включена та или иная опция ВМа.
.
Но в реальности, куда более вероятно, что найдут место где был неоптимальный запрос к БД и на этом все закончится. Ибо «кровавого энтерпрайза» куда больше чем «ХФТ и тд».

Казалось бы, где у меня там выше было хоть одно слово о БД, энтерпрайзе, string-ах, etc.
Узнаю бессмысленный и беспощадный dou.

А вот за этим пишутся коменты. В том числе в батниках вызова java, в настройках CMS, и даже файлики readme.txt
Да и сама структура проекта имеет доки. Если конечно это не нинзя-кодинг, он же фабрика классов ДваИндуса.

Підтримую.
Я взагалі-то плюсовик і вже давно не юзав Java, але ж пам’ятаю, що в них є два принципово різних типу ексепшенів. Нормальні, що доводиться чекати, бо воні можуть бути у нормальній програмі, та ті що «полний п» — як отой NullPointer. Оптимізувати «полний п» ексепшени — це дійсно «полний п».

По-перше, писав, під Android.
По-друге, в незалежно від мови програмування, для будь якої де взагалі є pointers та exceptions «оптимізувати» null pointer expception — ідіотизм.

Пожалуй, на счет «не взлетит», это я зря...

Когда автор жалобы осознает, что JVM это платформа, балансирующая между необходимостями прикладных разработчиков и «железячников», надеюсь, он перестанет рожать подобные опусы.

P.S. Тема не взлетит. Драматизьму мало.

Когда автор жалобы осознает, что JVM это платформа, балансирующая между необходимостями прикладных разработчиков и «железячников», надеюсь, он перестанет рожать подобные опусы.

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

JVM это платформа, балансирующая между необходимостями прикладных разработчиков и «железячников», надеюсь, он перестанет рожать подобные опусы.
А подробнее: как подобное поведение способствует такому балансу?
Пока это больше похоже на «накрутку результатов бенчмарков».
.
А если человек начал использовать исключение (и механизм их обработки) как управляющие структуры, то лучше его «наказать» пенальти по производительности, чем «заклеивать жвачкой кривизну его рук».

Вменяемый ответ на вопрос может дать только dtrace скрипт показывающий два результата (-XX:-OmitStackTraceInFastThrow / -XX:+OmitStackTraceInFastThrow) для некоего эталонного приложения обладающего признаками описанного поведения.

Все остальное — личное мнение.

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

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

Когда автор жалобы осознает, что JVM это платформа, балансирующая между необходимостями прикладных разработчиков и «железячников», надеюсь, он перестанет рожать подобные опусы.
Вменяемый ответ на вопрос может дать только dtrace скрипт показывающий два результата (-XX:-OmitStackTraceInFastThrow / -XX:+OmitStackTraceInFastThrow) для некоего эталонного приложения обладающего признаками описанного поведения.
В общем понятно: вы хотели сойти за умного, но у вас не получилось :)
.
Проблема выеденого яйца не стоит, честное слово.
Когда будете просматривать логи за несколько дней чтобы найти трассу, вспомните это слова :)

bit.ly/1sggh4C

P.S. Чем больше Вы будете знакомиться с творчеством performance инженеров Sun / Oracle, тем меньше будете принимать всерьез «статьи» состоящие из 3 параграфов.

И все-таки это не «баланс между необходимостями прикладных разработчиков и железячников», а банальное прикрытие своей Ж и, возможно, криворукости «особо важных клиентов».

Спасибо, Богдан, интересная находка.

Такое поведение, судя по документу (release notes), тянется с Java 5: www.oracle.com/...tes-139183.html

Выдержка из release notes:

The compiler in the server VM now provides correct stack backtraces for all “cold” built-in exceptions. For performance purposes, when such an exception is thrown a few times, the method may be recompiled. After recompilation, the compiler may choose a faster tactic using preallocated exceptions that do not provide a stack trace. To disable completely the use of preallocated exceptions, use this new flag: -XX:-OmitStackTraceInFastThrow.
For performance purposes
Моя версия, что все-таки накручивали бенчмарки :)

Увидим, Богдан. У меня аргументов против Вашего мнения пока нет :-)

А с кем соревноваться-то. Производителей JVM не так и много, и предпочитают одну другой не за бочку мёда, а за меньшее количество дёгтя.

А вот когда какая-нить серверная платформа типа GlassFish начинает срать стэктрейсами по каждому поводу — тут наверное нервы ребят не выдержали, и они написали костыли.

Кстати да, в теории такое может пригодиться, если «гдето чтото на продакшене посыпалось».

Подписаться на комментарии