company_banner

Производительность Java: настоящее и будущее

    Уже два десятилетия активно плодятся мифы о том, что приложениям на Java свойственны проблемы с производительностью. Одновременно с этим на Java создаются по-настоящему высоконагруженные системы. Кто же в конечном итоге прав? Чтобы составить мнение о том, как сейчас обстоят дела с производительностью Java, мы обратились к двум заинтересованным сторонам: создателям самой Java и клиентам, использующим Java в своих системах. На наши вопросы любезно согласились ответить Алексей Шипилёв (Oracle) и Олег Анастасьев (Одноклассники).



    Java Performance глазами создателей JDK



    JUG.RU: Расскажите, пожалуйста, о себе и о своей работе?


    Алексей Шипилёв: Меня зовут Алексей Шипилёв. Я работаю над производительностью Java уже более 10 лет. За это время я успел поработать над разными JVM — сначала над Apache Harmony в Intel, потом перешел в Sun Microsystems, где занимался OpenJDK. На текущий момент моя работа по большей части заключается в том, чтобы находить проблемы производительности в продукте и обозначать пути их решения или же исправлять собственными руками, если проблемы простые. Сюда входит и оптимизация под стандартные бенчмарки, тестирующие производительность виртуальной машины, и решение клиентских проблем (оптимизация их приложений), и улучшение глобальных вещей, которые необходимы многомиллионной экосистеме Java.


    JUG.RU: Как вы считаете, корректно ли вообще на сегодняшний день говорить о том, что производительность — проблема в целом Java, как технологии, а не отдельных приложений?


    Алексей Шипилёв: Об этом сложно говорить, поскольку производительность чаще определяется всё же кодом конечного приложения, а не задействованным для его создания языком. У языка программирования вообще нет производительности, она может быть только у реализации этого языка. Причем, различных реализаций может быть много. Однако в мире Java случилось так, что чаще всего речь идет о реализации JDK от Sun/Oracle, которая занимает более 95% рынка. Её и будем иметь в виду.
    В самом начале, в 1995 — 2000 годах, Java, как и всякий молодой продукт, действительно была не очень эффективно реализована. Но за последнее десятилетие в реализациях Java сделано настолько много, что проблемы, которые раньше считались типичными, перестали так сильно и так больно бить разработчиков по голове.


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


    Но важно помнить, что далеко не всем нужны высокопроизводительные решения: у многих разработчиков производительность не входит в список критериев успеха — "работает за приемлемое время" и хорошо. Если же разработчикам действительно нужна каждая последняя капля производительности, им придётся обходить подводные камни, которые присутствуют в любом достаточно сложном продукте (а виртуальная машина HotSpot — и OpenJDK в целом — очень сложный продукт).


    JUG.RU: Иными словами, производительность уже не является глобальной проблемой Java?


    Алексей Шипилёв: Думаю, да.
    Честно говоря, мне кажется, что проблемы производительности любой платформы — преувеличены. Как я говорил, большинство приложений не требуют большой производительности. Но в программистском сообществе существуют стойкие легенды и простые рецепты, которые очень удобно повторять (когда ты их повторяешь, кажется, что присоединяешься к группе посвящённых!). И одна из таких легенд заключается в том, что "Java тормозит". Лично я уверен, что она давно не релевантна. Для неё были объективные подтверждения лет 10-15 назад, но сейчас обстановка изменилась. Безусловно, и сейчас можно написать приложения, которые наступят на проблемы с производительностью в рантайме. Но эти проблемы в основном известны, для них есть обходные пути, а те, кому такие пути не подходят, создают собственные "костыли".


    JUG.RU: Насколько активно идёт развитие JDK и, соответственно, устранение известных проблем производительности (если говорить об Oracle JDK)?


    Алексей Шипилёв: Достаточно активно, и этому есть причина — экосистема Java очень большая, даже в пересчёте на одну компанию. У того же Oracle энтерпрайз-стеки написаны на Java. Соответственно, любое улучшение, которое делается в платформе, распространяется по всему стеку и облегчает жизнь в том числе и разработчикам Oracle. Но это история, почему Oracle развивает OpenJDK. Эта история в разных качествах повторяется и для других вендоров, и для других проектов с открытым кодом.


    JUG.RU: Какие последние нововведения в Java вам кажутся наиболее значимыми с точки зрения повышения производительности?


    Алексей Шипилёв: Во-первых, мне нравится, что история со сборщиком мусора Garbage-First (G1) потихоньку идет к логическому концу. Garbage-First был анонсирован давно, но только в Java 8 и 9 он стал себя довольно прилично вести, так что его можно использовать в промышленных масштабах — настолько, что в Java 9 он включён по умолчанию. Этот многолетний проект наконец-то выстреливает и делает вещи, которые задумывались с самого начала.


    Во-вторых, мне близка история с высокопроизводительными приложениями, которые требуют Unsafe, на замену части которого разрабатывается VarHandles. Есть легитимные случаи, когда хочется выжать последние капли производительности при помощи низкоуровневых хаков. Но Unsafe, как известно, — это приватный API, толком не стандартизированный, т.е. его использование — это бег с острыми ножницами по тлеющим углям горящего здания. А VarHandles — это один из путей, при помощи которого мы можем предоставить публичный API для таких редких, но важных случаев, когда нужна максимальная производительность или какая-то функциональность, которая иначе не доступна.


    Еще одно интересное нововведение — Compact Strings. Я лично участвовал в этом проекте и прочих "строковых" оптимизациях. Подобного рода изменения платформы, серьёзно улучшающие общеупотребительные классы, существенно повышают производительность вообще всех приложений, которые написаны на Java, и тем самым ещё больше снижают необходимость костылей.


    И в данном случае мы получили очень хороший результат не только на синтетике, но и на реальных приложениях. Достигнутое улучшение занимаемой памяти и производительности на 10% на больших приложениях — это очень хорошие приросты для такой здоровой взрослой платформы, как Java.


    JUG.RU: Раз уж мы говорим о производительности, существуют ли какие-то "канонические" методы её измерения? Сводится ли для бизнеса всё к деньгам?


    Алексей Шипилёв: Производительность не всегда переводится в деньги. На практике довольно сложно оценить, как прирост производительности влияет на экономическую сторону вопроса. Часто это косвенные эффекты — время, которое тратит программист на написание кода, укладывающегося в цели по производительности; время, которое тратят пользователи на ожидание результата, и т.п. Но с размещением серверов в облаках и плотных датацентрах производительность стала ближе к финансовой стороне вопроса: чем быстрее работает твоё приложение, тем меньше оно потребляет ресурсов, тем меньше ты платишь за аренду и обслуживание серверов. Причем эта зависимость в хорошо масштабируемых приложениях может быть просто линейная, т.е. разогнал на 50% свое приложение — тебе нужно в 2 раза меньше железа, платишь за инфраструктуру в 2 раза меньше.


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


    JUG.RU: Какие будущие нововведения в JDK, на ваш взгляд, наиболее ожидаемы с точки зрения управления производительностью?


    Алексей Шипилёв: Value Types — очень ожидаемое нововведение, которое на данный момент планируется реализовать к выходу Java 10. Это очень сложный проект, который требует подробного разбора, как он стыкуется со всей остальной платформой. "Священная корова" Java — это обратная совместимость. Нельзя сделать фичу, которая её сломает (точнее, можно сломать её в каких-то мелких моментах, но нужно очень хорошее обоснование, почему вы это ломаете, и какие у пользователя есть пути обхода).


    Value Types решает очень простую проблему. Одним из столпов Java как языка программирования является негласное свойство, что (практически) всё — объект. В этом кроется интересная грабля: проистекает она из того, что у объектов Java есть индивидуальные свойства. Например, идентичность (identity): если вы сделали объект, у которого записано число 42 в каком-то его поле, и второй объект, в котором лежит "такое же" число 42, то эти 2 объекта — разные с точки зрения языка, и отличаются как раз за счет identity. С точки зрения реализации, это означает, что и хранить нужно две отдельные копии этих практически одинаковых объектов — например, чтобы было где сохранить метаинформацию о них. И когда в приложении появляются большие графы объектов, накладные расходы для каждого объекта пожирают существенную часть полезной памяти. Было бы неплохо, если бы в языке были сущности без identity, для которых этого можно было бы избежать. И такие сущности есть: примитивы! Но их список жёстко зафиксирован. Естественное расширение — дать возможность декларировать сущности, которые записываются как классы, а работают как примитивы — это и есть value types.


    Value types существенно отличаются от привычных reference-типов. Например, является ли Object супертипом для всех value-типов? Логично, что нет, и тогда появляются тонкие моменты взаимодействия с дженериками, со специализацией и т.п. Есть библиотеки, которые делают подобного рода специализацию руками (тот же GNU Trove), но всем хочется, чтобы это было реализовано в самом языке. Так что эта очень ожидаемая фича: известно, какие бонусы она принесёт; известно сейчас, какие возникнут проблемы. Однако в ходе разработки мы посмотрим ещё, сколько там реально бонусов, а сколько проблем.


    JUG.RU: Учитывая, что проблемы производительности — скорее частные, нежели глобальные, можно ли говорить о какой-то типичной схеме при оптимизации приложений?


    Алексей Шипилёв: Существуют вполне конкретные методологии, которые предписывают, куда в первую очередь стоит смотреть на основании тех или иных симптомов. Мы с Сергеем Куксенко и прочими делали доклады на эту тему.
    К примеру, можно говорить, что у нас очень хорошие сборщики мусора, но, как ты не крутись, если будешь очень много мусорить, то в итоге сборка мусора будет занимать существенную часть времени. Какой рантайм ты не напиши, а если программист руками написал сортировку пузырьком или линейный поиск по массиву в 100 миллионов элементов, быстро не будет. Тут никакой магии нет — один дурак может такую задачку загадать, на которую семеро мудрецов не ответят.


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


    JUG.RU: А кроме сборки мусора какие есть типичные проблемы, легко поддающиеся оптимизации?


    Алексей Шипилёв: Мои любимые — проблемы с многопоточностью. Известно, что самый простой способ написать корректное многопоточное приложение — это щедро использовать синхронизацию. Я не говорю, что эта практика порочна,  но часто встречаются проблемы с тем, что аппаратные ресурсы используются не полностью из-за постоянных блокировок. Это очень легко диагностируется, и зачастую легко исправляется (часто, правда, требует правок в архитектуре).
    Очень часто встречаются алгоритмические проблемы, когда переписыванием плохих кусочков кода на хорошие кусочки, которые либо имеют лучшую алгоритмическую сложность в принципе, или каким-нибудь способом используют специфичные знания о данных в приложении, получаются гигантские приросты, которые никаким рантаймным оптимизациям и не снились.


    JDK/JVM-специфичные проблемы встречаются, но редко. Сюда падают и проблемы с плотностью данных в памяти (откуда нам опять машут рукой value types), и проблемы с высокоуровневыми оптимизациями (escape-анализ и автовекторизация, привет!), и проблемы с кодогенерацией. И тут скользкий вопрос — проблема в том, что рантайм плохой и не работает "правильно", или в том, что мы не хотим в данном случае как-то изменить решение, чтобы у нас была производительность лучше (например, использовать дополнительную библиотеку). Разные люди и разные организации смотрят на это по-разному.


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


    JUG.RU: Учитывая, что определенные проблемы всё же существуют, есть ли смысл использовать Java для высокопроизводительных приложений?


    Алексей Шипилёв: Знаете, когда я был школьником, один из моих преподавателей в ответ на ехидный вопрос кого-то из моих друзей, почему же мы не пишем на таком-быстром-С, сказал следующую вещь: "Я буду писать мой промышленный код на Pascal (популярном в те далёкие времена), потому что он везде мне подложит подстилки, везде всё проверит, не даст мне выстрелить себе в ногу. А в том месте, где мне важна скорость, я уж обману его так, чтобы было быстро". И эта история повторяется с разными действующими лицами и с разными языками: Pascal против C, Java против C++, C против ассемблера и т.п. На деле производительность большого приложения на горизонте вменяемых приростов, как правило, определяется производительностью довольно маленького куска в этом приложении. Поэтому может быть проще не буйствовать и не писать на языке, который вас заставляет писать низкоуровневый код, потому что вы с ума сойдете. Стоит писать на высокоуровневом языке, а там, где надо, обмануть его: сделать так, чтобы в конкретных местах было быстрее, перейдя либо к менее идиоматическому коду, повторяющему кривизну библиотек и рантайма, либо отдав тяжёлое на уровень ниже. Практика промышленной разработки на Java и история её производительности во многом этот подход олицетворяет.


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


    Java Performance глазами разработчика




    JUG.RU: Расскажите, пожалуйста, о себе и о своей работе.


    Олег Анастасьев: Я работаю в команде платформы в компании Одноклассники. Команда платформы разрабатывает программы для того, чтобы Одноклассники работали быстро, т.е. разрабатывает и поддерживает различные хранилища данных, фреймворки для коммуникации серверов друг с другом и т.п. Кроме того, если что-то с быстродействием случается на продакшене, именно команда платформы ищет решение, как это лечить. Наша ответственность — сделать так, чтобы Одноклассники работали быстро, потому что если они не будут работать быстро, они просто работать не будут — очень быстро завалятся под нагрузкой.


    JUG.RU: Как вы считаете, есть ли смысл использовать Java для высоконагруженных приложений? Или попросту нет альтернативы?


    Олег Анастасьев: Возможно, Java — не самый быстрый язык, существуют и более быстрые языки. Но если рассматривать Java, как язык для разработки больших нагруженных проектов, то здесь ей в принципе альтернатив пока нет. Можно написать более быстрый код на языках C или C++, но при этом этот код будет более дорогой — его написание, отладка и последующая поддержка будут стоить значительно дороже, чем аналогичный код на Java. Кроме того, к коду на C, который торчит в интернет, возникает очень много вопросов безопасности. Как известно, в языке С возможны всякие небезопасные конструкции, через которые потом нехорошие люди будут вас взламывать. На Java таких небезопасных конструкций меньше, поэтому в части безопасности программа на Java потребует меньших усилий.
    В итоге Java имеет очень хорошее отношение цена / производительность.


    У Java есть ряд проблем, в частности, нам пришлось отдельно работать над управлением памятью и поддержкой высокого трафика, но они могут быть решены при помощи небольшого количества кода — мы для этого создали отдельную библиотеку one-nio (ссылка на https://github.com/odnoklassniki/one-nio). Вся остальная масса кода обладает теми положительными чертами Java, которые у нее есть — быстрая разработка, безопасность, хороший инструментарий диагностирования проблем, встроенный в JVM, защита от ошибок и т.д.


    JUG.RU: Вы упомянули, что пришлось решать определенные проблемы производительности. Расскажите, пожалуйста о них подробнее?


    Олег Анастасьев: Для нас быстродействие — это не только скорость выполнения  кода на Java. Мы рассматриваем его и с ракурса эффективного использования ресурсов — то есть и объём обрабатываемых данных, и пропускная способность, и потребление памяти. И здесь в Java, действительно, много чего не хватает: коллекций примитивов, struct-ов, работы с оффхипом, прозрачного использования нативных API, управления affinity, файловыми кешами и т.д., поэтому нам приходится разрабатывать решения, которые позволяют обходить узкие места.


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


    Например, одна из болевых точек Java — это быстродействие ввода-вывода, как блокирующего, так и не блокирующего (в частности, сетевого).
    Это хорошо видно на примере раздачи видео. Общий исходящий трафик видео сейчас достигает 500 гигабит. Для того чтобы обслуживать такой поток мы должны раздавать видео как можно быстрее, чтобы как можно больше трафика приходилось на один сервер. Наше железо способно отдавать 40 Гбит с машины, но написать на Java при помощи стандартных решений сервер, который будет использовать все 40 Гбит у вас не получится — будет слишком много потерь в производительности внутри самой Java. Это одна из проблем, которые мы решали в составе нашей open source библиотеки.


    Пример с 40 Гбитным трафиком — это своего рода экстремум. Есть и менее нагруженные сервера, но там тоже присутствуют свои проблемы. Например, еще одна болевая точка Java — это хранение большого количества объектов в памяти. У Java есть garbage collector. С одной стороны, это хорошо, поскольку он позволяет автоматически убирать мусор. Но с другой стороны, когда вам нужно кешировать в памяти очень много информации, он скорее мешает, чем помогает. Более того, если массив данных на сотню гигабайт хранится в памяти, то вы захотите, чтобы он не потерялся при перезапуске программы — его загрузка займет значительное время. Такие массивы хочется хранить в разделяемой памяти, а встроенных средств в Java для этого тоже нет. В таких местах хочется иметь ручное управление памятью. Хорошо, что в Java есть Unsafe, через который мы и сделали собственное решение.


    JUG.RU: Развивается ли JDK в направлении решения специфичных для ваших задач проблем? Появляются ли новые опции, которые вы можете использовать?


    Олег Анастасьев: Последняя выпущенная в мир версия Java — 8. В ней решений упомянутых проблем нет. Есть только намерение решить какие-то из этих проблем в Java 9, часть из них — в 10 и более поздних. Но получится или не получится; насколько предложенные решения будут лучше, чем есть сейчас, говорить пока рано, т.к., например Java 9 еще не вышла. Конечно, бета-версию уже можно брать, но что изменится, пока она дойдет до релиза, не известно. Поэтому выйдет Java — посмотрим.


    JUG.RU: А есть ли какие-то ожидаемые нововведения, которые могли бы вам помочь? К примеру, VarHandles?


    Олег Анастасьев: Поможет или нет нам VarHandles зависит от того, как они в итоге будут реализованы в конечной версии, и как быстро они будут работать.
    VarHandles — довольно сложный способ даже с точки зрения API сделать то, что сейчас можно сделать просто и понятно через Unsafe. Это возможность объявить массив в памяти одного типа, а потом читать его, как массив памяти другого типа. Для человека, знакомого с принципами ассемблера или C, это выглядит как обращение по адресу памяти и считывание ячейки памяти, как Long или как Byte, в зависимости от ситуации. Грубо говоря, VarHandles позволяет сделать то же самое, но более сложно (это технически более сложное решение на уровне JDK), но зато он имеет больше защиты от программистов, которые периодически "стреляют себе в ноги".
    К тому же, VarHandles решают только один из сценариев использования Unsafe. Но мы используем Unsafe также и совсем для других сценариев (например, для кастомной сериализации или работы с разделяемой памятью), и альтернатив этому раньше Java 10 точно не ожидается.


    JUG.RU: На основании чего в вашей компании принимается решение о необходимости работы над производительностью приложений?


    Олег Анастасьев: Мы не занимаемся быстродействием ради быстродействия; всегда оцениваем экономический эффект от оптимизации.
    Для нас производительность измеряется в количестве денег, которые нужно потратить на железо: сначала на закупку серверов, а затем каждый год на их поддержку в дата-центре. Чем больше быстродействие приложений — тем меньше железа необходимо на ту же задачу, т.е. меньше денег уйдет на его поддержку.
    Оптимизация производительности отталкивается от поставленных задач. Можем ли мы позволить себе вот это количество техники для этой конкретной задачи?


    К примеру, потратить, условно говоря, год работы высококвалифицированного программиста, чтобы улучшить быстродействие на 0,5%, экономически не эффективно до тех пор, пока у вас не затронуты некой проблемой, допустим, все сервера в дата-центре. Тогда это будет экономически эффективно, и мы будем этим заниматься. Если нет, нам проще купить новых серверов, т.е. решить проблему железом.
    Для нас быстродействие — это бизнес-метрика; и она имеет четкое экономическое обоснование. Быстродействие пилится до тех пор, пока оно экономически эффективно.


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




    Больше интересных докладов, технических, хардкорных, вы найдете в программе Joker 2016. Предлагаем вашему вниманию несколько примеров:


    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

    Comments 209

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

      Какие небезопасные конструкции на С имеются в виду? Которых нет на java.
        +14
        Имеется ввиду класс проблем, связанных с buffer overflow в основном. Например, в Java незаметно выйти за границы массива невозможно — автоматически возникнет ArrayIndexOutOfBoundsException. Pointer arithmetics в Java нет как класса, что тоже не дает незаметно отстрелить себе ноги.
          +1
          На С++ можно точно так же написать систему простых классов-обёрток, которые будут всё проверять и не дадут выйти за границы нужной области памяти.
            +3

            Проблема в том, что С++ — это easy unsafe, hard safe. А Java и многие другие платформы — наоборот. На С++ надо постараться, чтобы не отстрелить себе ногу.

              +1
              Я согласен, что Java надёжнее. Но это не делает С++ языком, непригодным для написания надёжного и безопасного кода.
                +4
                Так никто и не считает что это невозможно. Речь о трудности и как следствие о стоимости разработки.
                  +4

                  На С++ возможно писать надёжный код. Но это не делает его оптимальным для такой цели.

          –28
          Нужно мне было писать скрипты, достаточно сложные, чтобы отказаться от bash и искать замену. Hello world на питоне (текстовый файл) запускается за 25 миллисекунд. Hello world на джаве (уже скомпиленный) запускался 100 миллисекунд. А таких экземпляров скриптов будет запускаться по несколько каждую секунду. Угадайте, что я выбрал?

          А насчёт тормозов авторы статьи правду говорят, не главная это проблема джавы, и джава — не главный тормоз. Первенство уверенно держит javascript, вебсерфинг такими темпами начнёт скоро требовать процов мощнее чем игрушки. Главная проблемы джавы — это адское потребление памяти. Я не видел ни одного человека, готового добровольно поставить такого прожорливого монстра на свой десктоп. Даже KDE приложения экономичнее чем прикладные приложения на джаве.
            +21
            и откуда вы все беретесь?
              +9
              Не ругайте таких людей. Это очень важно запускать Hello world по несколько раз в секунду
                –4
                Посмотрите в свой /usr/bin и сравните чего там больше — сложных бинарников или простых скриптов. Большую часть работы делают как раз приложения по 200 строк длиной, которые по времени работы от hello world практически не отличаются.

                Это важная сфера, и джава не способна решить проблемы скриптования никак. И разработчики это понимают и сами, пытаются решать проблему сверхжирного рантайма с помощью предзапущенной виртуальной машины (nailgun). Вот только java помимо производительности имеет ещё и проблемы с безопасностью: запущенные в одной машине скрипты интерферируют друг с другом, и через некоторое время запущенная JVM захламляется и становится непригодной к использованию.
                  +3
                  Мой комментарий просто шутка. Если вам нужны отдельные приложения и их запуск должен сопровождаться загрузкой и выгрузкой из памяти, то java действительно не ваш выбор.
                    +11
                    Это важная сфера, и джава не способна решить проблемы скриптования никак.

                    А она пыталась? Или вообще предназначена для этого? Это типа микроскопом гвозди забивать, как бы заезженно это не звучало.
                      +3
                      Большую часть работы делают как раз приложения по 200 строк длиной

                      Большую часть работы где?

                      Это важная сфера

                      Для админов?

                      сверхжирного рантайма

                      Рантайм не сверхжирный, а сверхпрокаченный. Скачайте исходники hotspot и cPython (раз уж приводили его в пример) и убедитесь сами, разница колоссальная. Банальный пример: шаблонный интерпретатор, который генерируется в рантайме и тупой switch по опкодам в while цикле. А еще наличие JIT (С2 с кучей оптимизаций) и нормального GC

                      с помощью предзапущенной виртуальной машины


                      По поводу времени старта, что-нибудь слышали про Class data sharing? Может немного снизить вашу боль.

                      запущенные в одной машине скрипты интерферируют друг с другом

                      Не очень понял, что конкретно имеется в виду, если про общие глобальные переменные (статические поля например), то попробуйте изолировать класслоадеры.
                        –5
                        >> запущенные в одной машине скрипты интерферируют друг с другом
                        > Не очень понял, что конкретно имеется в виду

                        Да тот же самый garbage collection у них общий. Или один поток внутри nailgun может сожрать проц и отнять ресурсы у всех остальных.
                          +5
                          И при чем тут JVM? Берите шире: «плохой» скрипт, запущенный отдельным процессом так же может выжирать ресурсы. Запустите fork-бомбу, например. И что теперь, OS плохая?
                            –5
                            Плохой скрипт запущен в собственном процессе. Этот процесс можно убить с помощью kill -9. С помощью kill -9 можно убить только nailgun целиком, отдельный скрипт внутри него убийству не подлежит, только все вместе, только коллективная ответственность.

                            От форк-бомбы можно защититься опять же на уровне процессов — ulimit. Вообще, операционная система сильно вкладывается в изоляцию процессов, это её основное предназначение. А разработчики виртуальной машины редко озабочены подобной функциональностью. Поэтому «эмулировать» операционную систему целиком на базе единственного инстанса jvm получается не очень.

                            P.S. Если кажется, что я вас игнорирую, то всё с точностью до наоборот — вы выбрали не получать от меня комментариев. Так что не обежайтесь, я вами не пренебрегаю, поддерживаю диалог по мере возможности.
                        +6
                        джава не способна решить проблемы скриптования никак
                        С точки зрения потенциальных возможностей, нет никаких ограничений, чтобы эффективно использовать Java для маленьких быстрозапускающихся программ. Для этого всего лишь нужна виртуальная машина, нацеленная на быстрый запуск, а не на продолжительное оптимизированное исполнение. Большой нужды в этом нет, потому что Java — это не скриптовый язык. Тем не менее, список виртуальных машин Java так велик, что, вполне возможно, есть реализации, соответствующие этому требованию.
                          +3

                          Для быстрого запуска даже готовое решение есть (хоть и коммерческое) — Excelsior JET.

                            0
                            Я не уверен, что оно так уж подходит для быстрого запуска маленьких программ. Так как минимальный размер исполнимого файла, который он создаёт, довольно велик.
                              +4

                              @pjBooms вроде уверял, что в 15 мегабайт удаётся уложиться для десктопных приложений. Большой размер исполняемого файла ещё не означает, что он медленно запускается.

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

                                  Насколько мне известно, исполняемые файлы загружаются с помощью memory-mapping'а: по факту подгружаются с диска только страницы, которые реально использовались.

                    +8
                    На Java не надо запускать новый процесс каждый раз когда нужно обработать http запрос. Сервер запускается 1 раз, слушает на 80 или 443 порту и обслуживает все запросы в рамках 1 процесса. На Java это достаточно просто, так как есть хорошие примитивы для работы с многопоточностью, памятью итп. Такая модель более эффективна, так как позволяет оперировать данными в рамках одного процесса, что значительно быстрее, например, походов в мемкеш на каждый запрос.

                    Как следствие, продакшен http запросы, связанные с формированием динамического html/json (естественно более сложные, чем hello world), полностью обслуживаются в среднем за 15-20мс. Не связанные с динамикой — быстрее.
                      –9
                      Я то думал, что джава — это универсальный язык, а не специальный фреймворк для написания http серверов. Я вот видел примеры десктопных программ для джавы, например azureus. И все эти программы жрут памяти больше чем надо.
                        +5
                        Я то думал

                        Думал

                        это универсальный язык

                        Нельзя быть универсальным и лучшим во всем.

                        И все эти программы жрут памяти больше чем надо

                        JVM в этом не виновата.
                        Вы знаете, сколько памяти занимает строка «Hello world» на джаве (hotspot) и том же питоне (cPython)? Какой оверхед дают заголовки объектов в обеих машинах? Cлышали про compressed oops? А то что в джаве есть примитивы, которые занимают по минимуму?
                        Следуя вашей логике, С++ тоже плохой, потому что современные браузеры выжирают кучу памяти
                          –13
                          > Нельзя быть универсальным и лучшим во всем.

                          Согласитесь, что в таком случае нечестно приводить самый лучший случай в пример. Большинству людей не нужно запускать у себя http сервер, им нужен десктопный и системный софт (скрипты). И вот в этом наиболее частом примере использования для обычного пользователя (а не корпорации гугл) java заметно проседает. Не спасёт её репутацию даже отличная (ах если бы) обработка http.
                            +2
                            Посмотрел на установленный на машине софт, из питона там разве что emerge. Как же так? Почему вы его привели в пример в своём исходном комментарии?
                              –3
                              Потому что писать маленькие скрипты рациональнее на баше. Если скрипты становятся сложнее — то тут и возникает выбор. Я вот лично пишу автоматизацию на питоне. Но серьёзно рассматривал и java в качестве выбора — питон меня угнетает отсутствием типизации. К сожалению вопросы производительности заставили отказаться от идеи использовать явы для скриптинга. А вопросы потребления оперативной памяти — от использования десктопных приложений.

                              И замечательная технология, в которую вложено дохрена человекочасов, которая должна была стать кросс-платформенной серебрянной пулей, не нашла на моем компьютере никакого применения. Обидно. И пока евангелисты явы отказываются принимать озвученные проблемы всерьёз, занять сколько-нибудь серьёзное место на компьютерах пользователей ява не сможет.
                                +1
                                А оно Ораклу-то надо, серьёзное место на машинах пользователей-то? Может, у них бизнес-модель немножко другая?
                                  –1
                                  Ну может ораклу и не надо. А вот фанатам, которые пытаются всюду пристроить яву и доказать, что проблемы с производительностью — это миф, пригодилось бы. Потому что на десктопах это миф. А сервера, где это было бы не заметно, есть не у каждого. Остальные лишь будут удивляться рассказам о быстрой и эффективной по памяти джаве.
                                    +1
                                    Фанатам тоже особо не надо. Ну, я не видел таких фанатов, которые бы пытались яву пристроить прям везде, от desktop environment до реализации wc, по крайней мере.

                                    Значит, просто, вы — не целевая аудитория этой статьи, джавы и так далее.
                              +4
                              Вы действительно считаете, что веб-серверы — не частый пример использования? Такое ощущение, мы с вами живём в разных мирах. Если не считать инструментов разработки, то у меня практически нет десктопных приложений. Я каждый день пользуюсь десятками, если не сотнями разных веб-приложенией. И у многих из них, не только у «корпорации гугл» миллионые дневные аудитории. И многие из этих веб-сервисов счастливо бегают в JVM. Это огромная ниша.

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

                              Это, конечно же, никак не уменьшает роль других элементов в стеке технологий: тех же bash-скриптов, которыми зачастую эти приложения деплоятся, или написанного на С linux, на котором всё это часто запущено. Но нельзя просто так сказать, что веб-серверы никому не нужны.
                                –2
                                В моём мире веб контент потребляется с помощью javascript, а не джавы. Что, кстати, тоже паршиво. А что лежит на сервере клиента волнует мало — .net, java или даже php. Если поставщику веб услуг не хватит производительности, он просто докупит ещё один сервер (это дешевле докупки программистов).

                                А вот на десктопе такая фишка не прокатывает, не любит обычный пользователь докупать железо, предпочитает менять программы на те, что не тормозят. Вот и приходится писать нативные программы на си(с плюсами). Кстати, веб серверы своей производительностью обязаны им же: базы данных, апач, nginx — все основные программы написаны на си. А веб приложение по большей частью занимается перекладыванием данных с места на место. А всё нетривиально вообще стало принято рендерить на стороне клиента.
                                  +2
                                  В вашем мире, вне зависимости от вашей точки зрения, веб-контент потребляется с помощью браузера. С помощью javascript делается нетривиальный интерактивный быстрый веб UI. И если не запускать разом десяток разных веб-приложений — вполне приемлемо, кстати. Только вы привыкли к старому вебу, где сайты были просто интерактивными страничками с длительным ожиданием перезагрузок для каких-либо действий и сложностями с восстановлением контекста. А это, не поверите, тоже требует ресурсов. Серьёзных ресурсов, ведь пускать в систему внешний код опасно. Приходится использовать более дорогое к ресурсам решение.

                                  Далее — клиента, действительно, не интересует, что лежит на сервере. Волнует скорость загрузки. Вконтактам пришлось вложить кучу средств на переписывании движка php. Просто потому, что стандартный с их нагрузкой не справлялся. А банки сразу используют .net или java — ибо целевая нагрузка известна, желания известны (нет необходимости прототипирования, с чего начался стартап «вконтакте»), а стоимость и скорость разработки + стоимость поддержки с учётом требований по надёжности+безопасности+доступности значительно ниже вариантов c/c++/php/python/ruby. Это при том, что средняя зарплата java-программиста выше зарплаты скриптовиков и на уровне c/c++. Аналогичным решением была выбрана java для веб-магазина Ulmart-а. И много где ещё.

                                  А на декстопе… ну у меня тоже java мало где есть. Сильнее всего выделяется Idea. Отзывчивый UI. Терпимая ресурсоёмкость. И офигительные возможности мощного IDE комбайна для разработки приложений.
                                  А ещё у меня есть android-фон. Там большинство приложений (представляете!) на java.
                                    –1
                                    > А ещё у меня есть android-фон. Там большинство приложений (представляете!) на java.

                                    Ну да, скорость, с которой разряжаются андроиды, вошла в поговорку.

                                    > В вашем мире, вне зависимости от вашей точки зрения, веб-контент потребляется с помощью браузера.

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

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

                                    Сначала он справлялся. И пользователю было всё равно, на чём крутится вконтакт, пока он крутится.

                                    > А банки сразу используют .net или java

                                    А что не си (опционально с плюсами)? Бывают веб-приложения на си, и они работают очень даже здорово.

                                    > стоимость и скорость разработки + стоимость поддержки

                                    А вот почему не си. Разрабатывать дорого. И рынок программистов уже. Поэтому ищется некоторый баланс, дайте нам язык не такой паршивый как php с точки зрения производительности, но и не такой дорогой в разработке как си. При этом условно php требует в два раза больше серверов чем python, java — в два раза меньше, а си — меньше в 4 раза. Но мы готовы удвоить количество серверов по сравнению с си, лишь бы сохранить простоту разработку (зато программист, который не умеет самостоятельно очищать память, стоит дешевле) и поддержки.

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

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

                                    > ведь пускать в систему внешний код опасно

                                    Знаю, у меня в браузере отключён javascript по умолчанию. Дополнительной опасности добавляет то, что javascript нынче — JIT компилятор, а не интерпретатор как в былые времена. Так что ошибки компиляции (выход за пределы массива, например), приводят к уязвимости движка js и соответственно браузера. Очевидно, надо откатится к тому моменту, когда js был интерпретатором и стойко терпеть десятикратное замедление работы. Просто не нужно вообще писать приложения в вебе. Приложения надо писать нативные. А веб — для веб страниц, передачи информации, а не деплоя приложений.
                                      0
                                      Просто не нужно вообще писать приложения в вебе. Приложения надо писать нативные. А веб — для веб страниц, передачи информации, а не деплоя приложений.

                                      Золотые слова, только уже поздно. Идея написания ядра приложений на своих серверах и взаимодействие с клиентом через ресурсоемкие и опасные технологии настолько захватила мир, что воевать бессмысленно.
                                        –1
                                        Наоборот самое время начать. Одно время в мире компьютерно железа царила проприетарщина, несовместимость и монополии. А пользователям приходилось учить зачем на компьютере кнопка «турбо». Потом железо стандартизировалось, появилось немного конкуренции и монополии перестали борзеть. На следующем этапе капитал сыграл в монополию операционной системы и прочего программного обеспечения. При этом те, кто хотел монополию для софта, продавливали открытость и взаимозаменяемость харда. Открытые аналоги в области софта долго отставали по возможностям, но наконец-то справились и предоставляют достойную альтерантиву. Теперь капитал играет в монополию над пользовательскими данными, и тот же гугол рекламирует открытость на нижележащем софтварном уровне, чтобы ему было удобнее зарабатывать на закрытой монополии данных. Значит настало время придумывать открытую альтернативу для хранения данных. Направление поисков очевидно — p2p и унификация клиентов-серверов, осталось только дождаться успешной хоть сколько-нибудь популярной реализации.

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

                                        Вышла виста, я посмотрел на то, что мой компьютер больше не мой компьютер и свалил на линукс целиком. Там тоже не было нормального jail, но там была культура разработки. Программы не портили жизнь друг другу, каждый занимался своим делом — unix way как никак. Один пакетный менеджер — и никакого бардака. От этого благополучия разработчикам линукса не было никакого острого побуждения делать свою ОС лучше. У них всё работает, зачем что-то менять? Опять же снобизм «зачем нам делать тюрьму — это же костыль для недоразработчиков, которые не умеют писать программы и следовать unix way?» Ну вот таких недоразработчиков оказалось очень много, и они перетянули за собой пользователей, чем может похвастаться андроид, который как сыграл на теме контролируемого запуска и тюрьмы для недоверенных приложений. Этот пример вдохновил и десктопописателей для наращивания функциональности тюрьмы в десктопных линуксах. Так что скоро веб перестанет быть единственным способом запускать недоверенные приложения, и можно надеяться, что браузер снова станет просмотрщиком страниц, а не киоском приложений.
                                        +1
                                        > Ну да, скорость, с которой разряжаются андроиды, вошла в поговорку.

                                        Хм… другие смартфоны выгодно отличаются от андроида? Не замечал. А поговорка возникла когда андроид был ещё сырой.

                                        > Для программирования веб страничек используется javascript. Для программирования современных браузеров — тоже, что хреново сказывается на потреблении ресурсов этими браузерами.

                                        Для программирования веб-страничем применяется стек: шаблонизатор + скриптинг + стили. Вы почему-то упоминаете только скриптинг, который предназначен для построения сколько-нибудь сложных UI. Кстати, для него применяются разные языки. В JS потом всё транслируется.
                                        Кстати, сами браузеры (ядра, движок, ...) пишутся на сях/плюсах. А ресурсы, которые они потребляют — не такие дорогие сейчас.

                                        > Сначала он справлялся. И пользователю было всё равно, на чём крутится вконтакт, пока он крутится.

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

                                        > А вот почему не си. Разрабатывать дорого. И рынок программистов уже. Поэтому ищется некоторый баланс, дайте нам язык не такой паршивый как php с точки зрения производительности, но и не такой дорогой в разработке как си. При этом условно php требует в два раза больше серверов чем python, java — в два раза меньше, а си — меньше в 4 раза. Но мы готовы удвоить количество серверов по сравнению с си, лишь бы сохранить простоту разработку (зато программист, который не умеет самостоятельно очищать память, стоит дешевле) и поддержки.

                                        Дорого — ещё пол беды. ДОЛГО! Очень долго! И выше риски безопасности. И ещё куча нюансов, да. А ещё Java хорошо (относительно) параллелится. На сях параллелить дороже. И серверов для Java требуется примерно столько же, сколько и на сях (максимум — на 5-10% больше), единственное — памяти приходится больше воткнуть. Ну и большинство Java программистов так или иначе программировало и на языках с прямым управлением памятью. Вопрос в том, что безопасней, т.к. даже лучшие программисты делают ошибки, а ошибки с управлением памятью дорого стоят.

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

                                        Фигню вы говорите. Тут играют несколько правил:
                                        — «кто раньше встал, того и тапки» — продукт, который успел выйти первым и удовлетворяет своим качеством пользователей имеет существенны приоритет перед конкурентами
                                        — маст-хев-фича — продукт, который содержит очень вкусную фичу, даже будучу глючнейшим — будет сохранять своих пользователей (пока фича не расползётся по конкурентам)
                                        — UI — положительно на выбор сказывается красивый+удобный или системный,
                                        — системные требования,
                                        — ценник,
                                        А теперь посмотрим на java-программы с точки зрения этих параметров:
                                        — большинство java-программ не являются пионерами, в этом параметре конкуренты успешно лидируют,
                                        — вот тут уже бывает по-разному. Например различные java based IDE выигрывают в забеге у редакторов и слабых IDE. Хоть тот Eclipse тормозная (на слабых и средних машинах) сволочь, но он очень массово распространён! А для Java почти все программы пишутся в тройке этих самых java based IDE. А ReSharper выигрывает у Visual Studio на своём участке.
                                        — IntelliJ Idea имеет приятные глазу функциональные скины. К сожалению у многих других java-приложений с этим беда (т.к. на разработку UI просто не оставляют ресурсов, а их надо много).
                                        — по системным требованиям java-программы плохо вписываются в слабое железо. Да, на Atom-е толстое java-приложение лучше не крутить. На средних машинах — всё становится уже вполне прилично (зависит от качества кода конкретной софтины)
                                        — ценник, ввиду меньшей стоимости разработки, что логично, пониже будет у java-программ.
                                        В итоге — некоторые java-программы выигрывают бой за десктопы. Не все, конечно. И, кстати, на сях порой тоже так напишут… что через час работы программы памяти и не осталось… Кстати, насчёт вашего примера с Azureus — это проблема конкретного приложения, а не java. А другие java-приложения вы видели? Ну и в любом случае началась ветка с вашей попытки приспособить java для скриптинга… извините, но если вы не сделаете/не заиспользуете спициальную java-машину, рассчитанную на частый запуск — java не подойдёт для такого кейса. Накладные расходы на запуск java-программ значимо влияют на скорость работы быстрых скриптов. С текущей реализация jvm java стоит применять только для каких-то серьёзных задач.

                                        > Знаю, у меня в браузере отключён javascript по умолчанию. Дополнительной опасности добавляет то, что javascript нынче — JIT компилятор, а не интерпретатор как в былые времена. Так что ошибки компиляции (выход за пределы массива, например), приводят к уязвимости движка js и соответственно браузера. Очевидно, надо откатится к тому моменту, когда js был интерпретатором и стойко терпеть десятикратное замедление работы. Просто не нужно вообще писать приложения в вебе. Приложения надо писать нативные. А веб — для веб страниц, передачи информации, а не деплоя приложений.

                                        Простите, что? Т.е. вы предпочтёте Active-x компоненты на страничках? Былых времён, к счастью, уже не будет. Актуальная ситуация — приемлемый уровень безопасности за приемлемый уровень быстродействия. И нет, приложения из веба уже не уйдут. Но люди «каменного века» могут ими не пользоваться. Никто не заставляет.
                                          –1
                                          > Дорого — ещё пол беды. ДОЛГО! Очень долго! И выше риски безопасности.

                                          Вот об этом я и говорю. Пользователь имеет свою точку зрения на это, отличную от бизнеса.

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

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

                                          > Простите, что? Т.е. вы предпочтёте Active-x компоненты на страничках?

                                          Вы меня совсем не поняли. Я вообще не терплю закрытых проприетарных программ на своём компьютере. У меня никогда нет флеша, и очевидно не будет active-x. Я предпочту, чтобы программы устанавливались системным пакетным менеджером, а не запускались из веба. Веб — не для программ. Зачем мне 100500 веб-чатиков, когда есть weechat?

                                          Понятное дело, пипл жрёт гавно, и веб программисты готовы предоставлять его сколько угодно, пока им платят. На многочисленные уязвимости, порождаемые таким подходом, насрать и пользователям, и программистам.
                                            +1
                                            Я вообще не терплю закрытых проприетарных программ на своём компьютере.

                                            И как вам живётся на машине как минимум восьмилетней давности с libreboot? Вот только не помню, есть ли HDD с открытыми прошивками..

                                              –1
                                              К сожалению, до уровня железа ещё не удалось добраться. Как только появится такая возможность — перейду.

                                              Кстати, вы случаем не пытаетесь провернуть https://en.wikipedia.org/wiki/Nirvana_fallacy#Perfect_solution_fallacy?

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

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


                                                А по самой проблеме Джоанна Рутковска где-то писала прекрасную вещь, что несмотря на наличие Intel ME жить и поддерживать современное железо как-то надо, поэтому Qubes OS не стремится работать на полностью свободном железе (как фанатично следующие заветам RMS), а стараются постепенно отвоевать позиции: на текущий момент ноутбуки, сертифицируемые под qubes уже требуют открытого boot firmware работающего в SMM. Но разрешает использование Intel FSP и ME.

                                              0
                                              >Веб — не для программ.
                                              В реальном мире нет такой ситуации, что есть Главное Действующее Лицо, его близкое окружение и множество остальных NPC. Поэтому для программ Веб или нет будет решаться явно в рамках данной дискуссии.

                                              Личные предпочтения могут быть любыми, а люди часто используют то, что удобно. У каждого человека своё хобби, круг интересов итд и многим совершенно не интересен любой другой подход кроме — нашёл в маркете пакет, установил, запустил и со 100% вероятностью всё заработало независимо от того, что было установлено/удалено ранее на устройстве, причём заработало означает что не требуется конфигурирование и вникание в убогий UI

                                              Тоже самое с языком «c» — для меня язык это инструмент с его экосистемой. Не редка ситуация, когда используется комбинация инструментов(языков) в зависимости от того, что я хочу сделать. Java очень удобна во многих случаях, (особенно когда проекты будут более 1кк строк) совсем не из-за псевдобесконечной памяти, а из-за очень небольшого количества undefined behavior, отличной обратной совместимости(старые модули работают) и хорошей системы сборки/пакетного менеджера. Если бы c++ имел бы также мало UB, такую же простоту изготовления крупных и особо крупных проектов и поддержку модулей, то скорее всего в крупных проектах именно он бы и использовался.

                                              >На многочисленные уязвимости, порождаемые таким подходом, * и пользователям, и программистам.
                                              Уязвимости порождаются UB. В том же JEE или Spring изначально есть поддержка безопасности и шанс встретить уязвимость гораздо ниже чем в приложениях, которые созданы дёшево и на языках с UB.

                                              На фронэнде JS или WebAssembly работает в песочнице, что позволяет пользователю выполнять приложения из Сети гораздо безопасней чем раньше, а открыть url куда проще, чем устанавливать пакет и вникать как сделал интерфейс автор пакета, который совершенно не разбирался в том, как делать хорошие интерфейсы, а потом вникать — а не накосячил ли автор пакета в том, что остаётся мусор после удаления пакета
                                              p.s.
                                              Мир очень сложен, но в тех местах, которые не разведаны в течение десятка лет всё кажется обманчиво простым и примитивным
                                                –2
                                                > Личные предпочтения могут быть любыми, а люди часто используют то, что удобно.

                                                Чаще всего они используют то, что есть. Сколько раз обвиняли гугол в том, что он делает пользователю неудобно, когда меняет интерфейс почты. Ему всегда было насрать, старый интерфейс отключался, новый занимал его место. А вот если бы почтовый клиент был обычным приложением, а не веб, то клиенты ставили бы себе то, что удобнее. Кто-то выбрал бы новый интерфейс, кто-то остался бы на старом.

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

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

                                                > На фронэнде JS или WebAssembly работает в песочнице

                                                В песочнице может работать что угодно, это не прерогатива javascritpt. Кстати из-за желания запускать песочницу недоверенный бинарь хрома требует себё ещё и админских прав.

                                                > как сделал интерфейс автор пакета, который совершенно не разбирался в том, как делать хорошие интерфейсы,

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

                                                > Если бы c++ имел бы также мало UB, такую же простоту изготовления крупных и особо крупных проектов и поддержку модулей, то скорее всего в крупных проектах именно он бы и использовался.

                                                Очевидно, что для написания программ на си необходим настоящий программист, а для джавы — достаточно ПТУшника. Но я не понимаю, как конечные пользователи могут радоваться этому факты и приветствовать костыли, созданные специально для понижения квалификации изготовителя программ. Как же набившая оскомину реклама «вы достойны лучшего»?
                                                  +1
                                                  >Чаще всего они используют то, что есть.

                                                  Так же никто не запрещает создать конкурента гуглу, лучше гугла, не напрягающего пользователей и делающего пользователям максимально удобно и приятно и всё это standalone
                                                  >А те, кто разбирается в интерфейсе, не умеют программировать без GC. Как бы их подружить друг с другом? >Пользовательские программы и мир стали бы лучше.

                                                  Какая разница есть GC или нет? Память это один из множества ресурсов. В java нет нормального автоматического управления ресурсами, поэтому любой разработчик даже знающий только java уже прекрасно умеет управлять ресурсами и памятью его научить управлять можно за минимальное время, т.к. паттерны почти такие как ручное управление всеми остальными ресурсами. В C++ на мой взгляд заметно удобней сделано управление ресурсами. Не умение управлять памятью разработчиками java и сакрализация этого величайшего знания это какой-то городской миф уровня медведей, греющихся на ядерных реакторах в Советской России.

                                                  >Очевидно, что для написания программ на си необходим настоящий программист, а для джавы — достаточно ПТУшника

                                                  Тот факт, что для написания программ на Си нужны квалифицированные программисты не совпадает с суровыми реалиями в которых программисты сильно разные и корреляция с языками весьма слабая. На чём и зарабатывает компания, продающая единорога

                                                  И квалифицированным программистам никто не запрещает пилить сложные проекты на java, не теряя скорости разработки при наборе более 100 тыс строк кода и получая другие преимущества(автоматическое управление памятью к ним не относится)

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

                                                  > Но я не понимаю, как конечные пользователи могут радоваться этому факты и приветствовать костыли, созданные специально для понижения квалификации изготовителя программ

                                                  Ну не знаю, та же win98 сделана известно на чём и это был страшнейший треш и угар. Да и linux/gnu тех времён тоже доставлял по страшному да и сейчас доставляет порой веселья с новым железом.

                                                  На моей памяти как раз нативные приложение наиболее неудачно и вредительски глючили
                                                    +1
                                                    > Чаще всего они используют то, что есть. Сколько раз обвиняли гугол в том, что он делает пользователю неудобно, когда меняет интерфейс почты. Ему всегда было насрать, старый интерфейс отключался, новый занимал его место. А вот если бы почтовый клиент был обычным приложением, а не веб, то клиенты ставили бы себе то, что удобнее. Кто-то выбрал бы новый интерфейс, кто-то остался бы на старом.

                                                    Не нравится гугл и его замшки? Кто мешает уйти на яху? На другой почтовый сервис? К тому же тот же яху позволяет почтовые клиенты. Но ведь всем же гмейл давай! Так? Бред а не аргумент.

                                                    > Так вот, не надо говорить, что пользователи довольны таким ходом вещей, только потому что они продолжают пользоваться гуглом. У них нет выбора, гугол сознательно лишает выбора своих клиентов, потому что он хочет контролировать весь процесс от и до. И не он один, именно поэтому бизнес предпочитает сейчас оказывать услуги и одалживать веб-приложения вместо того, чтобы продавать standalone приложения по-старинке. Бизнес можно понять, причём легко — он заботится только о прибыли.

                                                    Выбор пока ещё во многом есть. Вот только веб-приложения выбираются уже не менее редко, чем десктопы. К чему бы это? Мобильные платформы начинают поддерживать веб-совместимые приложения как нативные! К чему бы это? Ну а насчёт компаний и софта-как-сервис — всё просто, это позволяет компаниям иметь предсказуемый доход. Очень удобно. Пользователи тоже зачастую довольны — тот же фотошоп стал доступен в лицензионном виде многим из тех, кто раньше даже не задумывался о его покупке.

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

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

                                                    Извините, но это разные классификации. Есть хреновые веб-приложения, есть хреновые десктопные приложения. Это не признак веба. В вебе, кстати, чаще встречается более-менее адекватное ПО и оно, к тому же, постоянно улучшается. Нет, другие есть. Альтернатива есть всегда. В худшем случае — в горизонте полугода появится альтернатива. Да я ж безумно рад, что многое легковесное ПО ушло в веб или имеет веб-клиент! Мне не нужен почтовый клиент на каждом компьютере — я гляну через веб! Мне не нужен банк-клиент от каждого банка, где есть мой счёт — я воспользуюсь вебом! И да, насмотрелся я в своё время на «эффективные десктопные приложения». Спасибо — не надо. Что вы выбирите: отставание ПО на 10к лет от текущего положения, страшнейшую глюкавость или ценник х10? Вот это то, к чему вы призываете, сделайте свой выбор!

                                                    > Очевидно, что для написания программ на си необходим настоящий программист, а для джавы — достаточно ПТУшника. Но я не понимаю, как конечные пользователи могут радоваться этому факты и приветствовать костыли, созданные специально для понижения квалификации изготовителя программ. Как же набившая оскомину реклама «вы достойны лучшего»?

                                                    Совсем-то бред-то уже не пишите! Если вы поставите «ПТУ-шника» на java — то и получите говно на палочке. Тормоза и глюки. Для написания хороших программ java требует ничуть не меньшей квалификации, но вот детских болезней у неё меньше, инструментарий у неё лучше — это позволяет писать тяжелое ПО быстрее и с меньшим количеством багов!
                                                      –1
                                                      > Что вы выбирите: отставание ПО на 10к лет от текущего положения, страшнейшую глюкавость или ценник х10? Вот это то, к чему вы призываете, сделайте свой выбор!

                                                      Это плохой выбор. Отставание на 10 лет — это не свойство десктопных приложений, а свойство непопулярных приложений. А популярность — целиком вопрос выбора пользователей. Если они выберут десктоп, то получат десктоп.

                                                      > Не нравится гугл и его замшки? Кто мешает уйти на яху? На другой почтовый сервис?

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

                                                      > Совсем-то бред-то уже не пишите!

                                                      Так это не я придумал. Это мне выше фанаты явы указали как неоспоримое достоинство явы — для джавы проще обучить программиста.
                                                        0
                                                        > Это плохой выбор. Отставание на 10 лет — это не свойство десктопных приложений, а свойство непопулярных приложений. А популярность — целиком вопрос выбора пользователей. Если они выберут десктоп, то получат десктоп.

                                                        Это выбор, который придётся сделать при переходе на более тяжелые в разработке языки.

                                                        > Так это не я придумал. Это мне выше фанаты явы указали как неоспоримое достоинство явы — для джавы проще обучить программиста.

                                                        Проще обучить != использовать неграмотного специалиста.
                                                          +1
                                                          > Это выбор, который придётся сделать при переходе на более тяжелые в разработке языки.

                                                          Мы жили на этих языках до сих пор. На них написаны ОС и сама джава. Написано куча софта. Некоторый софт даже достиг 100% функциональности и заморозился, как например screen. Так что вопрос достижения нужной функциональности на нативных языках — это всего лишь вопрос фокусировки внимания. Если писать не на джаве, то будут появляться приложения не на джаве. И работать так же успешно. Правда стоить будут в два раза больше.
                                                        +1
                                                        Для написания хороших программ java требует ничуть не меньшей квалификации, но вот детских болезней у неё меньше, инструментарий у неё лучше — это позволяет писать тяжелое ПО быстрее и с меньшим количеством багов!

                                                        Не совсем согласен. Допустим имеем бизнес приложение, уровня excel. Если мы будем писать его на С, то надо нанять 1-3 программистов для написания ядра приложения и немного кодеров для написания обвязки или тестирования. Приложение по сути будет монолитом, который написали конкретные люди. Если писать на java, то нужно сразу 20 джава сеньоров и немного кодеров, тестировщиков. Но во втором случае программист не будет центром разработки. Приходит менеджер на работу, настроение плохое, пошел уволил парочку сеньоров, что они без шапок ходят и вообще будут знать! Оставшиеся классы объекты между собой раскидали, кое-что переписали и всё хорошо. А вот придет менеджер на работу и уволит одного программиста на С из трех, при условии, что софт изначально на С. И может всё сломаться, от слова совсем. Именно по этой причине java популярна среди работодателей, а вовсе не потому, что в языке для работы с оперативной памятью требуется библиотеку писать.
                                                        Про уход программ в интернет, совсем всё просто. Во первых, вы не оплатите один раз установку десктоп программы, вы легко подсядете на подписку и будете платить всегда. Во вторых, если в новой версии программы рекламные блоки будут размещены более эффективно для ctr, то вы можете десктоп приложение не обновить. А с веб-приложением такой вольности позволить уже не получится. Альтернатив часто нет. Решение только одной задачи смены рекламных блоков на экране — оправдывают любые затраты. Поздно уже о десктоп приложениях думать.
                                                        ps
                                                        Это моё личное мнение, я могу и ошибаться.
                                                          +1

                                                          Какое-то предвзятое и неаргументированное мнение.


                                                          Если мы будем писать его на С, то надо нанять 1-3 программистов
                                                          Если писать на java, то нужно сразу 20 джава сеньоров

                                                          Это с чего вдруг? Если хватает 1-3 программистов на C, то уж программистов на java нужно не больше. А зачастую даже меньше.


                                                          Но во втором случае программист не будет центром разработки.

                                                          А кто будет?


                                                          А вот придет менеджер на работу и уволит одного программиста на С из трех, при условии, что софт изначально на С. И может всё сломаться, от слова совсем.

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


                                                          Оставшиеся классы объекты между собой раскидали, кое-что переписали и всё хорошо.

                                                          А c-программисты в ноги целыми днями друг другу стреляют. Стереотипы такие стереотипы.


                                                          Кстати, интересно, сколько вы работали в команде и на каких языках писали?

                                                            +2
                                                            у java есть несколько крупных сфер применения и обычно она используется не для сайтов-визиток с баннерами, а для больших корпоративных систем или для android.

                                                            В корпоративных системах 5 минут простоя системы может стоить очень много бабок, т.к. скажем компания в N тыс человек парализована, а зарплата им всем идёт. Поэтому если разработчик знающий Си готов взять ответственность под залог своего имущества, например что выбор не принесёт огромных убытков из-за segfault, ложащего всю систему, а в случае сбоя на продакшне он обязуется очень быстро всё починить, либо всё быстро оплатить, то разрешат пилить на Си его модуль. Но что-то мне подсказывает, что разработчик лучше резко выучит java, чем будет рисковать большим баблом.

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

                                                            Да, на java тоже можно сделать так, что произойдёт отказ всей системы, но шанс гораздо ниже и шанс быстрого подъёма системы очень высоки и менеджера не будут иметь за самовольный выбор технологии, когда на java ни у кого не падает, а у нас Си и всё плохо. Да, тут заметную часть выбора делает репутация java, но опять таки ничего(кроме необходимости огромных инвестиций) не мешает сделать такую же репутацию любым другим экосистемам
                                                              +1
                                                              bromzh, struvv прочитал Ваши комментарии. Развивать дискусию смысла не вижу, так как в принципе я с Вами согласен. Сейчас все бегут на java и «программы» в браузере, да и ладно, побежим вместе.
                                                              Обратите внимание, как Вы интересно защищаете технологию. Программист на С обязательно должен рискнуть своей зарплатой и его код всё равно упадет. А программист на java ничем рисковать не должен. Во-первых, потому что java не упадет. Во-вторых, потому что менеджеру не попадет за то, чо он выбрал java. Но ведь я пишу о том же. java выбирается работодателями, потому что программист потом становится один из многих. А С программист он один. В итоге удивительная ситуация, но центр разработки — это менеджер. А программисты java — просто обслуживающий персонал.
                                                                +2
                                                                А С программист он один. В итоге удивительная ситуация, но центр разработки — это менеджер. А программисты java — просто обслуживающий персонал.

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

                                                                  0
                                                                  Скажите, а вы эту ерунду говорите, исходя из своего опыта, или вам кажется, что всё должно быть именно так?

                                                                  Из поста struvv я сделал такой вывод.
                                                                    +1
                                                                    Речь шла исключительно о определённых областях применения. И ещё раз хочу напомнить, что нет такого противостояния рас — java программист vs С программист. Это два инструмента, и не редки случаи, когда их используют вместе. Один разработчик как правило знает несколько языков

                                                                    Я пропустил много пояснения «по умолчанию». Сейчас я их напишу. К настоящему моменту существует множество библиотек на java, которые всё ещё работают из-за прекрасной обратной совместимости языка, плюс есть множество легаси проектов, которые также сделаны на java. При запуске нового проекта мы уже оказываемся в какой-то экосистеме и мы несём определённые риски, решив сделать проект, например на хаскеле. И если он внезапно провалится, то отвечать будет тот, кто выбрал хаскель, даже если он провалится по иной причине.

                                                                    Или например если мы пишем драйвера, то выбор — Си, так как есть определённый пласт истории, уже сложившаяся экосистема. Если же мы выбираем какой-то другой язык, то нужны определённые обоснования и будет дополнительная ответственность за выбор.

                                                                    Вот чтобы сдвинуть текущее состояние дел должен быть переломный момент в истории, как например появление самого языка СИ, который решал определённые проблемы с переносимостью плюс кто-то должен проинвестировать переписывание тонн программ, очевидно им не хочет быть тот, кто предлагает всё переписать. И чтобы был переломный момент, когда начали переписывать обратно с Java на C/C++ — мне очень сложно представить необходимость в этом.

                                                                    Напомню с чего начиналось это сообщение — для разработчика языка это всего лишь инструменты. Лично я пробовал делать какие-то задачи на необычных языках(для своей экосистемы). Всегда сталкивался с нехваткой библиотек. И мне сложно представить за чей счёт будет делаться аналог Spring или GlassFish на том же Си, а также портирование всего полезного что есть в репозитории maven. И самое главное — зачем это нужно. Кто получит преимущества и какие?
                                                          0
                                                          Так вот, не надо говорить, что пользователи довольны таким ходом вещей, только потому что они продолжают пользоваться гуглом. У них нет выбора, гугол сознательно лишает выбора своих клиентов, потому что он хочет контролировать весь процесс от и до.

                                                          Пользуюсь гмылом с самописного клиента через IMAP, что я делаю не так?
                                                            0
                                                            Всё так. Вы отказались от использования гугловского клиента. А варианта поставить более старую и удобную версию у вас никогда не было. Не знаю, почему вы выбирали самописный клиент, но многие выбирают как раз потому, что веб версия деградирует по возможностям и дизайну.
                                                              0
                                                              Возможно дело в том, что сегодня интерфейс активно выбирают методом А и B тестирования. Основными целями является повышение ctr или реклама каких-то внутренних сервисов привязывающих пользователя к сайту. В то же время обычный пользователь интуитивно противится навязыванию и улучшенному отображению рекламных блоков.
                                                              То есть требуется интерфейс с блоками, которые можно расположить по своему и скрыть не нужные. Только кто в таком случае оставит блок с рекламой?
                                                                0
                                                                Не знаю, почему вы выбирали самописный клиент

                                                                Потому что я графоман и люблю всякое самописное.
                                                          +1
                                                          > Вот об этом я и говорю. Пользователь имеет свою точку зрения на это, отличную от бизнеса.

                                                          Не смешите мои тапочки — последние остались. Средний пользователь хавает то, что раньше вышло, если нет серьёзных нареканий. А серьёзных нареканий у большинства не будет — атомы всё же редкость, 2 гига оперативы — тоже редкость. На остальных платформах разницы между нормально написанной java-программой и каким-нибудь качественным тяжёлым сайтом вы не заметите. А качественными тяжёлыми сайтами — пользуются. Да ещё и нахваливают! Вы не смешивайте среднего пользователя и ваше видение ситуации — это совершенно разные вещи.

                                                          > Ну да, поэтому Idea и живёт. Но как только появляется возможность сменить джаву на си реализацию, ей немедленно будут следовать. Но от этого к ноуту разработчика появляются дополнительные требования, которым ноуты здоровых людей уже не удовлетворяют. Всё ради того, чтобы запускать джаву, без которой не получается зарабатывать деньги. С этим приходится жить, но радоваться не приходится. Спасает только то, что для некоторых языков emacs имеет поддержку не хуже чем Idea.

                                                          Idea живёт потому, что: на нормальном железе работает эффективно и не тормозит, при этом предлагает очень эффективный инструментарий и быстрое его развитие. Нет ни малейших шансов переписывания её на си/плюсы — слишком большие требования к надёжности, расширяемости, скорости развития. Никакой аналог на сях/плюсах не сможет её догнать и обогнать… разве что если каждая копия будет стоить как боинг. Чтобы оправдать увеличение штата программистов раз в 10. И ноуты здоровых людей — удовлетворяют требованиям вполне. Уж 4-то гига оперативки и i3 поставить туда не проблема. Есть корректные бюджетники за приемлемую цену с нужными параметрами. Вот только программировать на ноуте — то ещё убожество безотносительно производительности: маленький экран, неудобная клавиатура, и очень неудобно работать в паре со вторым монитором. А насчёт емакса — зря вы холивор затеваете. Не канает редактор против IDE. Никак не канает

                                                          > Вы меня совсем не поняли. Я вообще не терплю закрытых проприетарных программ на своём компьютере. У меня никогда нет флеша, и очевидно не будет active-x. Я предпочту, чтобы программы устанавливались системным пакетным менеджером, а не запускались из веба. Веб — не для программ. Зачем мне 100500 веб-чатиков, когда есть weechat?

                                                          А зачем мне weechat, если там никого нет? Я зайду в уютненький скайп — там у меня есть контакты. Нет, майкрософт делает всё, чтобы люди оттуда ушли, но другие чатилки ещё только приближаются к нужному порогу популярности, а скайп уже имеет. Системный пакетный менеджер это замечательно!.. НО СКОЛЬКО ЖЕ РАЗ я читал в руководствах «как пофиксить такую-то проблему в linux» куски рекомендаций вида «добавить в список репозиториев такой-то, установить из него то-то». ЭТО не системный пакетный менеджер. Это та же порочная практика, что и установка винсофта с шаринг-хостеров. И да — в 10ке вроде наконец-то появился пакетный менеджер. а без active-x/java, например не организовать массово-удобный механизм электронной подписи. Да и в других ситуациях для своего времени active-x/java applets/flash были очень полезны. Сейчас большую часть их задач съел html5 + js… Вот только не все.

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

                                                          Пипл не гавно жрёт, а функционал. На качество — в среднем им действительно наплевать. И я вам про то и объясняю — на java получается менее гавно, быстрее, эффективно! Потому и лезет она из всех щелей, даже на десктоп прорывается периодически.
                                                            0
                                                            > Средний пользователь хавает то, что раньше вышло, если нет серьёзных нареканий.

                                                            Потребление ресурсов — серьёзное нарекание. По этому по возможности пользователь переходит на нативные приложения. Что заметно на примере того же iOS и андроид

                                                            > Нет ни малейших шансов переписывания её на си/плюсы — слишком большие требования к надёжности, расширяемости, скорости развития.

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

                                                            > очень неудобно работать в паре со вторым монитором

                                                            А вы попробуйте расположить второй монитор над ноутбуком.

                                                            > А насчёт емакса — зря вы холивор затеваете. Не канает редактор против IDE. Никак не канает

                                                            emacs — это среда исполнения, а не редактор. Чего хотите, то и запускайте в нём. Тот же sunrise commander более продвинут чем midnight commander при том, что emacs — это вроде как редактор, а не файловый менеджер.

                                                            > Я зайду в уютненький скайп — там у меня есть контакты.

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

                                                            > ЭТО не системный пакетный менеджер.

                                                            А почему вы отождествляете пакетный менеджер с хранилищем пакетов?

                                                            > Пипл не гавно жрёт, а функционал.

                                                            Ну функционал, а контент. Функционала всё меньше становится в новых программах. А людей просто выбора нет.

                                                            > на java получается менее гавно, быстрее, эффективно!

                                                            На java получается эффективная разработка, с этим никто не спорит, но не эффективные программы
                                                +2
                                                «Не спасёт её репутацию даже отличная (ах если бы) обработка http.»
                                                Ну это вы конкретно загнули… Репутации Java ничего не угрожает. Посмотрите на индекс Tiobe. Думаете язык, на котором нельзя написать нормальных программ смог бы занять такую позицию?

                                                «Лучший пример»
                                                В данном случае правильнее писать не «лучший пример использования языка», а «пример, в котором язык лучше». И это довод. Только не довод пихать во все щели, а вот в заданном примере использовать можно.

                                                И да, мне почти не нужны скрипты. В основном мне хватает системных. В крайнем случае — на баше напишу. На Java скрипты писать не буду — дурость. Вот если вычисления хотя бы на минут 10 работы понадобятся — тогда задумаюсь. Если софтина десктопная понадобится — подумаю стоит ли связываться (UI на Java возможен, но непрофильная для меня тема). Сетевой сервис поднять понадобится — точно возьму java. А питон ни в одном случае не возьму — мало того, что я его не знаю (было бы желание — можно было бы выучить), так ещё и неоднократно натыкался на тормозящие питоновские скрипт-программы…
                                                  –2
                                                  > Думаете язык, на котором нельзя написать нормальных программ смог бы занять такую позицию?

                                                  Писать можно конечно. А вот желающие поставить себе на десктоп джаву в очередь не выстраиваются.
                                            +9
                                            Ох, чувствую, накликаю я беды на свою карму этим комментарием, но все же выскажусь в поддержку Saffron. Я не против Java, даже люблю этот язык и пользуюсь им, но объективно программы на ней работают не так уж и быстро.

                                            В свое время я тоже проводил тесты сравнения производительности «Hello World»-приложений, написанных на Java и PHP. И у меня так же Java-программа оказалась заметно медленнее, причем прогонов было много, JVM успела «разогреться». Я тоже, как и вы, подумал, что это проблема запуска JVM. Действительно, реальные Java-приложения работают в постоянном режиме и расходов на запуск JVM у них нет.

                                            Тогда я, как вы и предположили, решил протестировать работу Java-прораммы в режиме сервера — один процесс обслуживает тысячи http-запросов. Я сделал и однопоточную реализацию, и многопоточную разными способами, эти программы были мега-примитивны и просто не имели права тормозить. Никаких сервлетов и прочего EE, точно ServerSocker на чистом Java SE. И каково же было мое удивление, что однострочный PHP-скрипт, запущенный не под самым быстрым веб-сервером Apache, отвечал быстрее на тестах Apache Benchmark.

                                            После этого у меня просто опустились руки. Ну как же так?! А если вспомнить про оконные приложения, где тормоза видны невооруженным взглядом… Что-то в мире Java идет не так.

                                            Вы пишите про парсинг JSON. Но, опять же, не факт, что он будет происходить быстрее, чем в скриптовых языках, ведь в последних за такие операции обычно отвечают модули, написанные на Си. И я вполне допускаю, что работа с JSON у Java так же может оказаться не самой быстрой.

                                            Справедливости ради, хочу заметить, что на операциях с большими массивами и сложными вычислениями Java работает ощутимо быстрее скриптовых языков. Но с другой стороны, скриптовые языки ведь создавались не для этого. В общем, все сложно…
                                              +10
                                              Тестировать hello world почти всегда бессмысленно. Но вот результаты правильно поставленных тестов сериализации JSON. как видно решения на Java занимает 2 место, сразу после C, различные решения на Java занимают 6 позиций из 10 в топе.
                                              Если у вас что то не получилось, возможно, вы что то делали неправильно.
                                              У Java более высокий порог вхождения, чем у, условно, PHP. Это имеет свои и положительные и отрицательные стороны, конечно.
                                                –1
                                                Все, что вы написали разумно и с вашими доводами я во многом согласен. Но у меня есть свое мнение по этому поводу, которое не позволяет мне согласиться с вами полностью. Дальнейшее обсуждение этого вопроса приведет к пустому спору, поэтому я на этом закончу :)
                                                  –3
                                                  Ну сравните эклипс и визуал студию.
                                                    +5
                                                    У нас в коллективе все используют разные IDE. Код на C++ — просто огромный. Анализатор дробит связи долго. Так вот, QtCreator тормозит существенно меньше, чем Eclipse. Это видно «невооружённым глазом». Казалось бы, нагруженный фреймворк. И обе IDE активно применяют многопоточность. Кстати, у нас Visual Studio тупит даже больше, чем Eclipse. IntelliJ IDEA тупит немного меньше, чем Eclipse, но тут сравнение проводилось на Java-коде и не столь огромном. Машины одинаковые.
                                                      +4

                                                      Рискну предположить, что на 80% эта разница обусловлена качеством реализации оперирования кодом, алгоритмами, фичами. И на 20% — разницей c++/java

                                                        0
                                                        Возможно и так. Кстати, сам код правится через SMB-протокол прямо на виртуалках — для экономии времени и исключения лишних веток в SVN. Вот тут есть одна проблема: IDE не видят напрямую стандартные либы. Они подключаются как дополнительный каталог. Как это влияет на анализатор, трудно сказать. Он и там и там задумчив.
                                                        +1
                                                        У QtCreator предельно унылая code model. Не могу сравнить с Eclipse, правда, он мой проект вообще не прожевал :(

                                                        CLion, впрочем, у меня тупит ну где-то на уровне KDevelop.
                                                        0
                                                        Как мне их сравнить, если VS на моей машине не запускается ввиду линукса? Она заведомо проиграла, получается, или как?
                                                          +1
                                                          Оба хуже. Студия уже давно не 6й версии. Вот та, можно сказать, летала на тогдашнем железе. Нынешняя железо уже давно обогнала.
                                                        +3

                                                        а можно код тех бенчмарков посмотреть? что-то мне не верится что php может быть быстрее

                                                          +15
                                                          А у вас не осталось, случаем, этого теста с Java сокетами? Я почти уверен, что его можно улучшить.

                                                          Каких я только баек не слышал про тормозную Java! В большинстве своём они возникают как раз от неумения бенчмаркать и анализировать. У меня на StackOverflow целая подборка ответов про курьёзы Java Performance. Вот, например:


                                                          На самом же деле, с производительностью Java есть ровно две проблемы:

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

                                                            +1
                                                            Шикарная подборка!
                                                            +9
                                                            И у меня так же Java-программа оказалась заметно медленнее, причем прогонов было много, JVM успела «разогреться».

                                                            Видимо, вы не понимаете, что такое «разогрев» JVM, если вы считаете, что после некоторого количества перезапусков JVM она как-то там разогревается.

                                                          0
                                                          Hello world на джаве (уже скомпиленный) запускался 100 миллисекунд

                                                          Написал Hello world, запустил тысячу раз в цикле из батчика, заняло 67 секунд, то есть 67 миллисекунд на запуск, а не 100 (Java 8u92 64bit, Windows 7). Комп пятилетней давности, жёсткий диск самый обычный. Если уж ругаете джаву, приведите хотя бы условия тестирования.

                                                          +4

                                                          Да начнется срач о тормозящей Java!


                                                          Java медленнее С++? Смотря когда. Ну ладно, допустим относительно сложный код, написанный гуру своего языка (невероятная редкость). Да, медленнее. Тут сложно понять джавистов — зачем с пеной у рта пытаться опровергнуть очевидное.


                                                          Значит ли это, что Java хуже? Да нет же. Она лучше по куче других параметров: безопаснее, быстрее разработка, больше разработчиков.


                                                          И тут возникает вопрос — не будет ли проще и дешевле написать на Java, чем на C или C++? Так ли критична вам производительность, или разаработка на С++ будет стоить больше чем дополнительная пара плашек памяти в ваш сервер или еще пара минут ожидания для пользователя? Нет, конечно если вы пишете движок для игры, браузер или числодробилку, без плюсов никуда (хотя некоторым людям из одной известной компании захотелось и рыбку съесть, и сами знаете куда сесть и так получился Rust, посмотрим что из него выйдет, а другим показалось, что достойных конкурентов не так уж и много, а машины у программистов производительные, поэтому и IDE можно на Java писать). Но многие ли из нас пишут движки для игр и браузеры?


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

                                                            +8
                                                            Конкретно вопрос холивора быстродействия Java vs C/C++ наиболее полно осветил Cliff Click здесь

                                                              +1
                                                              Внезапно, очень крутой доклад. Почему-то не натыкался на него раньше. Спасибо.
                                                                +4
                                                                Почему внезапно? :) Клифф же был автором JIT в JDK. Он шарит!
                                                              +6
                                                              машины у программистов производительные, поэтому и IDE можно на Java писать


                                                              Каждый раз когда вижу нападки в сторону гуев на джава, смотрю на свою идею и пытаюсь вспомнить схожий по сложности продукт, написанный на нативном языке без глюков и работающий так же быстро.
                                                              На больших проектах требуется ссд, без него все медленно, но язык тут не причем. Такое количество файлов и библиотек требует быстрого хранилища.
                                                              Однако, я знаю достаточно тормознутые гуи на джаве, например тот же SQLDeveloper.
                                                                0
                                                                смотрю на свою идею и пытаюсь вспомнить схожий по сложности продукт, написанный на нативном языке без глюков и работающий так же быстро.

                                                                Я начал с того, что конкурентов мало. Но они все таки есть: KDevelop, Qt Creator. Не совсем без глюков, но и CLion не идеален, особенно если учитывать что это коммерческий продукт. А еще Visual Studio, по некоторым параметрам вообще эталонная IDE.


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

                                                                На моем ноутбуке SSD, 8 гигов оперативы и, хоть и ультрабучный, но всё же i7, но на больших проектах этого мало.

                                                                  0

                                                                  К KDevelop давно не притрагивался, но если сравнить QtCreator двухлетней давности как C++ IDE с IDEA того же времени как Java IDE, то QtCreator — блокнот с отладкой, а не IDE.


                                                                  VS очень давно не использовал, так что сравнивать не возьмусь. Хотя популярность ReSharper'а намекает, что в VS по функциональности многого не хватало.

                                                                    0

                                                                    Ну я бы не сказал, что VS или KDevelop несравнимы с CLion (в котором тоже некоторых вещей не хватает) по сложности.

                                                                      +1

                                                                      CLion пока на начальном этапе, а VS и KDevelop существуют и развиваются на порядок дольше. Поэтому я сравнивал с idea, а не с clion.


                                                                      Когда я начинал пользоваться qtcreator'ом, то там ни простых рефакторингов, кроме переименования, который не всегда работал корректно; ни мало-мальски нормального автодополнения.

                                                                        0
                                                                        а VS и KDevelop существуют и развиваются на порядок дольше.

                                                                        Когда появились VS и KDevelop, реализовать большую часть современных фишек было нереально. Другое дело, что разработчики VS прошляпили момент, когда их пора было добавлять. KDevelop же имхо по фичам CLion'у не сильно проигрывает.


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

                                                                          –1

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


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

                                                                            +1
                                                                            Да, хотя багов при этом в таком софте часто выше крыши

                                                                            В 90% софта багов выше крыши.

                                                                    +1
                                                                    SSD, 8 гигов оперативы и, хоть и ультрабучный, но всё же i7, но на больших проектах этого мало.
                                                                    Заголовок спойлера


                                                                    Нет, серьёзно, я у себя на домашнем ПК был вынужден поставить 16 гб оперативки, ибо с 8 гб всё уходило в своп. Про системный диск на HDD вообще вспоминать не хочется. А когда-то… ну вы и сами знаете.
                                                                +2
                                                                Хорошое интервью. Спасибо!

                                                                P. S. А это правда, что Алексей уходит из Оракла :)?
                                                                  0
                                                                  Я вот удивился статье, думал он уже ушел.
                                                                  –2
                                                                  Шел 2016й год, а про unsigned в java мире все так и молчат. Неужели никому не надо прочитать long из массива байт? Неужели криптография в java всегда будет ассоциироваться с & 0xFFFFFF?
                                                                    –8
                                                                    А зачем шифровать, если java на 95% безопаснее C?
                                                                      0
                                                                      Не только криптография, но и вообще множество разных протоколов.
                                                                      А молчат, потому что изменения нужны серьезные, боятся сломать совместимость.
                                                                        –1
                                                                        Полагаю, что эта одержимость совместимостью и станет лебединой песней java. Языки и технологии, не привязанные к legacy, развиваются куда динамичнее.
                                                                        +1
                                                                        а про unsigned в java мире все так и молчат.

                                                                        Как нативный тип unsigned не нужен и вреден. Спросите у Andrey2008, сколько багов в C++-программах из-за этого unsigned. Если необходима unsigned-интерпретация существующих типов, в Java всё есть. Например, Integer.parseUnsignedInt(), Integer.divideUnsigned() и т. д.


                                                                        Неужели никому не надо прочитать long из массива байт?

                                                                        LongBuffer lb = ByteBuffer.wrap(bytes).asLongBuffer(), дальше делайте lb.get(), чтобы читать лонги. В чём проблема?

                                                                          +1

                                                                          Багов много из-за гадости под названием "неявное приведение". Уберите неявное приведение между знаковыми и беззнаковыми — и всё внезапно становится гораздо лучше. Хотя в Java оно может и не так сильно нужно.

                                                                            +3

                                                                            for(size_t x = 10; x>=0; x--) { ... } — а тут где неявное приведение?

                                                                        –5

                                                                        А очень-очень медленные регулярные выражения в Java будут исправлены когда-нибудь?

                                                                          0

                                                                          Очень-очень — это насколько? Из моего опыта они сопоставимы таковым в perl и cpython.

                                                                            0

                                                                            Очень-очень это в 2-3 раза медленнее, чем PHP, Python (даже не CPython), NodeJS.

                                                                              0

                                                                              А какая тогда реализация python использовалась? У v8 и php реализация на C.

                                                                                –1

                                                                                Python3
                                                                                http://ideone.com/3w5A7Z
                                                                                Java
                                                                                http://ideone.com/dwqy55
                                                                                На IDEone разница 3 раза, на моей локальной машине (Python35 Java8) разница в 2 раза.
                                                                                Запустите тесты на своей машине, если не сложно. Может быть в Вашей реализации Python он будет соизмерим по скорости с Java.

                                                                                  +4

                                                                                  Бенч на java без прогрева? Seriously?

                                                                                    –7

                                                                                    На сим прекращаю спор с Вами. Вы не понимаете сути проблемы, к сожалению.
                                                                                    Никто никогда не будет применять одно и тоже регулярное выражение к одному и тому же тексту 500000 раз и ждать когда прогреется JVM, чтобы запустить JIT-компиляцию.

                                                                                      +4

                                                                                      В чём проблема? Прогоните разные регекспы на разных текстах. Прогрев всё равно нужен, потому что код движка регекспов надо JIT-компилировать (безотносительно того, одинаковый регексп или разный).

                                                                                      –3

                                                                                      А моим пользователям тоже объяснять, что чтобы не тормозило, они должны сначала прогреть Java?

                                                                                        +2

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

                                                                                          –2

                                                                                          Бенчмарки должны быть хоть как-то приближены к реальности. В тесте сверху матчится 500000 регэкспов, и этого для прогрева судя по всему недостаточно.

                                                                                            0

                                                                                            Я думаю, в сто раз меньше бы хватило.

                                                                                              –2

                                                                                              Я не эксперт по прогреву Java, я просто вижу тест где матчится 500000 регекспов и java отрабатывает медленнее, и на это говорят, что проблема в прогреве.

                                                                                                +2
                                                                                                на этого говорят что «меряют сферического коня в вакууме и в дополнение неправильно»
                                                                                                но большинству достаточно цифр из желтых газет чтобы начать истерить
                                                                                                  –2

                                                                                                  Тем не менее непрогретая Java остается любимым аргументом против любых бенчмарков. Я не против Java, я даже не заявляю что бенчмарк корректный. Я просто считаю, что прогрев это не серебренная пуля и не надо его приплетать к любому бенчмарку Java. Если мой софт будет тормозить из-за того, что Java непрогрета, никто не скажет, что всё ок.

                                                                                                    +5
                                                                                                    Я просто считаю, что прогрев это не серебренная пуля и не надо его приплетать к любому бенчмарку Java.

                                                                                                    К любому не надо. Инженеры Оракл, например, измеряют отдельно производительность JIT-компиляторов C1 и C2, а также влияние изменений на стартап JVM. Термин «прогрев» сам по себе довольно обывательский, если вы не знаете точно, какой код у вас каким JIT-компилятором с каким профилем скомпилирован в данный момент. Измерение производительности — сложная наука, что, конечно, не мешает высказываться по этому поводу множеству неэкспертов.


                                                                                                    Если мой софт будет тормозить из-за того, что Java непрогрета, никто не скажет, что всё ок.

                                                                                                    Так давайте обсуждать конкретный тормозящий из-за регекспов софт, а не дурацкие бенчмарки! У вас есть на примете Java-софт, который тормозит из-то того, что Java непрогрета?

                                                                                                      –5
                                                                                                      Измерение производительности — сложная наука, что, конечно, не мешает высказываться по этому поводу множеству неэкспертов.

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


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


                                                                                                      У вас есть на примете Java-софт, который тормозит из-то того, что Java непрогрета?

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

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

                                                                                                        Вот тут и кроется ваша логическая ошибка. Я легко приведу примеры тестов на Java, которые в рамках примитивного бенчмарка будут работать в 1000 раз медленнее, чем в реальном приложении. Также легко приведу примеры тестов, которые будут в примитивном бенчмарке на порядки быстрее, чем в реальном приложении. Не умея писать бенчмарки для конкретного языка, вы легко попадёте в подобную ловушку и измерите чёрт-те-что.


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

                                                                                                        Ну так давайте все тесты делать без прогрева. Замеряйте время от включения питания компьютера до получения результата на экране. Почему вы замеряете время в уже «прогретой» системе, где операционка и стандартные разделяемые библиотеки уже загружены в память? Вы же так не любите прогрев.

                                                                                                          –2
                                                                                                          Я легко приведу примеры тестов на Java, которые в рамках примитивного бенчмарка будут работать в 1000 раз медленнее, чем в реальном приложении.

                                                                                                          Вопрос в том, можете ли вы привести пример тестов, которые будут работать точно так же, как в реальном приложении.

                                                                                                            +2
                                                                                                            Что вы подразумеваете под «реальным приложением»?
                                                                                                            «Реальные приложения» бывают разные. И даже в одном «реальном приложении» код будет находиться в разных условиях.
                                                                                                            Если вы хотите замерить производительность для горячего кода в долгоживущем (например серверном) приложении, то в случае java вам к jmh (примеры кода), введение от автора.
                                                                                                              +2

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


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

                                                                                                    +5

                                                                                                    Окей, один неэксперт рассуждает о производительности Java, ссылаясь на тест другого неэксперта. Так победим.

                                                                                                  0
                                                                                                  как минимум там не тест, а кусочек говнокода:

                                                                                                  1) делать замеры производительности на ideon само по себе глупо
                                                                                                  2) в примере java происходит измерение в одном интервале «медленного режима интерпретатора» и «быстрого скомпилированного», общее число 500мс совсем не говорит о том какого режима было больше, а напоминает известный анекдот

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

                                                                                                  итого на моей системе получаем устоявшуюся скорость:
                                                                                                  1) nodejs 100ms
                                                                                                  2) java 200ms
                                                                                                  3) python 400ms

                                                                                                  зря @rossws сразу не привел примеры его java кода сразу, было бы меньше вопросов про прогрев и итерации
                                                                                                    0

                                                                                                    1) У Вас Copy/Paste сломались для теста на своей машине?
                                                                                                    Идеон только как удобное средство размещения кода.

                                                                                            +1

                                                                                            Результаты на моей машине:


                                                                                            • python 3.5.2 — 600 ms;
                                                                                            • python 2.7.12 — 545 ms;
                                                                                            • openjdk 1.8.0_102 — 250 ms (после 10 итераций цикла по i для прогрева), 275 ms после однократного прогрева и 1060 ms без прогрева.
                                                                                              0

                                                                                              Прогрейте так:


                                                                                              public static void main (String[] args) throws java.lang.Exception
                                                                                              {
                                                                                                  Pattern pat = Pattern.compile( ".*a.*?b.*" );
                                                                                                  boolean b;
                                                                                                  String text = "             a                      b                      ";
                                                                                                  Matcher m;
                                                                                                  for ( int i=0; i<5000000; i++ ) {
                                                                                                      m = pat.matcher( ""+i );
                                                                                                  }
                                                                                                  long t1 = System.currentTimeMillis();
                                                                                                  for ( int i=0; i<500000; i++ ) {
                                                                                                      m = pat.matcher( text+i);
                                                                                                      b = m.matches();
                                                                                                  }
                                                                                                  long t2 = System.currentTimeMillis();
                                                                                                  System.out.print( t2 - t1 );
                                                                                              }

                                                                                              А если хотите сравнить результаты после JIT-компиляции, то давайте сравним с PHP, а не Python- так будет честно.
                                                                                              Когда сработала JIT-компиляция на этот кусок бесполезного цикла, то уже нельзя сравнивать результат с результатом Python.

                                                                                                +1

                                                                                                В первом цикле нет m.matches(), т. е. значительную часть вы не прогреваете. С добавлением этого фрагмента производительность реализация на java работает за 600-700 ms, а аналог на python3 (с text + str(i), естественно) за 850-950 ms (python2 — 750-850 ms).


                                                                                                Часто ли у вас изменяются регулярки в процессе работы программы? Если вы их берёте не из PRNG, то оно вполне может прогреться за долю реального времени работы программы и вы получите результат не хуже, чем в python.


                                                                                                В любом случае, давно написанная и отлаженная pcre или реализация в perl'е (обе на C) с запасом в 2 раза бьют всю эту шушеру. С другой стороны, 1.2 us на пачку выделений памяти, конвертацию строки в число, конкатенацию строк и применение регулярки — не столь плохо, чтобы об этом парится. Если php использует pcre, то будет выигрывать максимум в те же 2 раза. Какой будет реальный разрыв — судить не берусь, не представляю внутренностей php и hhvm.


                                                                                                Если же ваша задача так упирается в скорость применения регулярок — перепишите фрагмент на C, используя pcre и дёргайте через JNI или JNA (опять же, если дополнительные затраты на JNA не пугают).

                                                                                                  –2

                                                                                                  Я знаю с какой скоростью все это работает из коробки и знаю как все это можно ускорить, поэтому делаю только те заявления, которые мной лично проверены.
                                                                                                  Когда нужно много регулярных выражений- использую PHP. В нем можно использовать весь синтаксис PCRE.

                                                                                                    +3

                                                                                                    Заявление, что регулярки в java медленнее оных в python, кажется, тоже вы делали чуть выше. Но проверено вами совсем не это (судя по вашему "benchmark'у"). Факты и ничего кроме фактов.


                                                                                                    Если у вас выполнение регулярок занимает больше 10-20% времени работы программы (и это подтверждается профилированием), и нужные регулярки работают одинаково, то нет повода не использовать более быструю реализацию. Если же вы вступаете в область, где поведение python-re/python-regex/pcre/perl/j.u.regex разнится — то приходится выбирать исходя из необходимого поведения, а не мериться скоростью. Make it run, make it right, make it fast. А не наоборот.

                                                                                                      –9

                                                                                                      Повторяю еще раз с уточнением: без JIT-компиляции регулярные выражения Java вдвое медленнее Python.
                                                                                                      Меня поражает свойство некоторых людей спорить до упора и наверно еще свято верить в свою правоту.
                                                                                                      Ваши аргументы в этом споре:


                                                                                                      1. Надо задействовать JIT- так будет быстрее, чем в Python
                                                                                                      2. На крайний случай можно задействовать JNI
                                                                                                      3. Ой, да и вообще, регулярные выражения мало кто использует, а если и использует, то непременно в большом цикле с предварительным прогревом
                                                                                                      4. Если производительность не просела именно от регулярных выражений- зачем вообще говорить о их производительности

                                                                                                      Зачем Вам это нужно?
                                                                                                      Вы фанатик Java?
                                                                                                      Я Вам привел примитивный тест, который Java проваливает в 2 раза. Могу поэкспериментировать и найти узкие места реализации движка из-за которых Питон обгонит Java в 3 и более раз, но зачем мне это? Доказать фанатикам что-либо нереально- они не видят очевидного.
                                                                                                      Спор ради спора- это Ваша цель?

                                                                                                        +6
                                                                                                        Меня поражает свойство некоторых людей мерить скорость java программы без JIT'а. Это как мерить скорость у не заведенной машины.

                                                                                                        Зачем вам это нужно?
                                                                                                        Вы фанатик интерпретации программ?

                                                                                                        Если ваша программа отрабатывает быстрее, чем успевает JIT скомпилиться, то не пишите её на java.
                                                                                                          +3

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


                                                                                                          Вы не поняли почему я задавал уточняющие вопросы? ОК, объясню. Любая реальная программа на java (напомню, что скрипты на jvm-языках — это немного нонсенс) будет успеет прогреться в процессе использования, и некоторые потери производительности в начале улучшают ситуацию в дальнейшем.


                                                                                                          Если производительность не просела именно от регулярных выражений- зачем вообще говорить о их производительности

                                                                                                          Если у вас выполнение регулярок занимает 1%, а работа с DAO — 20% активного времени, например, ответа на запрос, то ускорение первых в 2 раза даст прирост скорости всего на 0.5%, а такое же ускорение второго даст 10%. Обычно нет никакого резона тратить время на оптимизацию, которая, фактически, не даёт профита. Обыкновенный прагматизм.


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

                                                                                                            +1
                                                                                                            скрипты на jvm-языках — это немного нонсенс
                                                                                                            Да ладно. Я вполне регулярно применяю скрипты на groovy в качестве Nagios local checks. Время выполнения, измеренное командой time, укладывается в 50-60 ms, меня устраивает. И да, совет переписать это скажем на python, будет заведомо проигнорирован — потому что это именно с него было переписано. В итоге было достигнуто существенное упрощение кода, и сокращение времени на доработки.
                                                                                                              0

                                                                                                              Понятное применение. Как, скажем, в том же gradle. Когда накладные расходы на запуск, как в вашем случае, относительно невелики по сравнению с временем между запусками check'а, то почему бы и нет. Другой вариант — использование инфраструктуры языка: check дергающий что-либо по JMX логичнее писать на java или groovy.


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

                                                                                                                0

                                                                                                                Вот-вот. JMX. Схватываете на лету )

                                                                                                                  0

                                                                                                                  Проблему с JMX можно решить завернув его в JSON на стороне Java: https://jolokia.org/

                                                                                                                    0

                                                                                                                    Только теоретически )) А на практике jolokia — это если у вас скажем под рукой только python, и вам позарез нужно сделать именно на нем.


                                                                                                                    Вы пробовали реально через jolokia посмотреть скажем метрики Apache ActiveMQ?


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


                                                                                                                    jolokia умеет за раз только один MBean, а из groovy скрипта я их достаю сколько мне нужно, и формирую ответ из результатов множества вызовов.

                                                                                                            +4
                                                                                                            Да, действительно в hello world тестах java часто заметно уступает другим реализациям других языков. Но бенчмарки не интересуют бизнес. А при промышленной эксплуатации мы видим совсем иную картину.

                                                                                                            Когда речь идёт о java, то как правило подразумевается java world, а не java lang. В данный момент есть несколько java world, два самых крупных — Java в бэкэнде(это jee, jse+spring и другие варианты) и java + android framework.

                                                                                                            В энтерпрайз/web backend мире разработчик тратит деньги компании впустую, если задумывается о том, как ускорить, например, регулярки, до обнаружения, что вообще есть тормоза и они внезапно возникли не из-за хранилища, а из-за того, что регулярки тормозят. И так как серверные приложения максимально прогреты(можно заметить, что компилятор работает первые несколько рантайма минут почти непрерывно), то это значит только то, что надо нести расходы — либо на ФОТ для того, чтобы разработчик(и) оптимизировали данный участок кода,
                                                                                                            либо на железо.
                                                                                                            Причём при использовании в энерпрайзе дополнительное железо часто сильно дешевле, чем вклад денег в оптимизацию.

                                                                                                            В android world совсем другая VM, сейчас в ней используется AOT компиляция, соответственно проблемы производительности редко когда начинают быть заметны. Другое дело — особенность обработки событий в android приложениях из-за чего каждый второй разработчик пишет вычисления прямо в потоке отрисовки из-за чего пользователь чувствует лаги интерфейса. Тут могла бы помочь программа проверки выкладываемых приложений, но гугл не заморачивается. Как правило в android приложения страдают от небольшого количества памяти, которая доступна на устройствах, а не от нехватки cpu.

                                                                                                            Если наступает такой момент, что не хватает cpu/памяти, то разработчик просто берёт и пишет c/c++ код и использует его через JNI. Ну или всё пишет на c++, если это какая нибудь картография.

                                                                                                            Таким образом в промышленной эксплуатации упереться именно в затыки в реализации java/JVM очень сложно. Почти всю работу делает JIT и делает её прекрасно. Но это всё речь идёт о применении JVM для достаточно сложных проектов в >1кк строк кода, работающих на мощном железе и обслуживающих множество пользователей — тут java раскрывает всю свою мощь. Понятное дело что для сайтов визиток, браузеров, компьютерных игр дешевле использовать другой набор инструментов.

                                                                                                            У java своя область применения и в этой области и язык, и экосистема имеют высокую конкурентоспособность по совокупной стоимости разработки и владения.
                                                                                                        +1

                                                                                                        Если критична скорость применения регулярок, можно сперва попробовать альтернативы на той же Java. Например, TCL-re, который на конечном автомате. Для определённых семейств регекспов может быть сильно быстрее.


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

                                                                                                          +1

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


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

                                                                                                  • UFO just landed and posted this here
                                                                                                    • UFO just landed and posted this here
                                                                                                        +7
                                                                                                        Глаза режет не правда, а глупость.
                                                                                                        Во-первых вот хороший комментарий, показывающий, что ваши бенчмарки — фигня. Прочитайте внимательно все пункты и постарайтесь понять.
                                                                                                        Если вы за java пример брали это, то вы хотя бы понимаете, что делаете?
                                                                                                        Вы знаете, что делает exec в js и matches в java, в чем разница? А знаете какой аналог из java более близок к тому, что в примере js?

                                                                                                        Вообще мне начинает казаться, что это хорошо, что у кого-то тормозит джава. Пусть используют что-то другое, а у нас будет чуть выше порог входа. Судя по комментарием, некоторые любители скриптов не до конца понимают, что такое JIT, зачем он нужен, делают далеко идущие выводы, основываясь на недобенчмарках
                                                                                                        • UFO just landed and posted this here
                                                                                                            +10
                                                                                                            Подождите, вы хвалите NodeJS, но при этом хаяете Java за то, что там GC и JIT? Или я не так понял?
                                                                                                              +2
                                                                                                              А на Java точно нужно столько же тестов, сколько на NodeJS? Или всё-таки часть проверок покроет тайпчекер?
                                                                                                              • UFO just landed and posted this here
                                                                                                                  +2
                                                                                                                  Я, кстати, когда первый раз запускал js-тесты в проекте, думал, что что-то не так сделал, потому что они моментально отработали. Оказалось, что они и правда безумно быстро пробегают.
                                                                                                                  • UFO just landed and posted this here
                                                                                                              • UFO just landed and posted this here
                                                                                                                  +3

                                                                                                                  было бы чего добиваться, hello world на nodejs работает в 3 раза медленнее, чем аналогичный сервлет в томкате.


                                                                                                                  hello.js
                                                                                                                  var http = require("http");
                                                                                                                  
                                                                                                                  http.createServer(function (request, response) {
                                                                                                                     response.writeHead(200, {
                                                                                                                      'Content-Type': 'text/plain', 
                                                                                                                          'Connection': 'Keep-Alive',
                                                                                                                          'Content-length': 11
                                                                                                                     });
                                                                                                                  
                                                                                                                     response.end('Hello World');
                                                                                                                  }).listen(8081);

                                                                                                                  hello.java
                                                                                                                  package hello;
                                                                                                                  import java.io.*;
                                                                                                                  import javax.servlet.*;
                                                                                                                  import javax.servlet.http.*;
                                                                                                                  
                                                                                                                  public class HelloServlet extends HttpServlet {
                                                                                                                      @Override
                                                                                                                      protected void doGet(HttpServletRequest request, HttpServletResponse response)
                                                                                                                              throws ServletException, IOException {
                                                                                                                        response.setContentType("text/plain");
                                                                                                                        PrintWriter out = response.getWriter();
                                                                                                                        out.println("Hello World");
                                                                                                                      }
                                                                                                                  }

                                                                                                                  benchmark nodejs
                                                                                                                  ab -n 100000 -k -c 16 http://localhost:8081/
                                                                                                                  This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
                                                                                                                  Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
                                                                                                                  Licensed to The Apache Software Foundation, http://www.apache.org/
                                                                                                                  
                                                                                                                  Benchmarking localhost (be patient)
                                                                                                                  Completed 10000 requests
                                                                                                                  Completed 20000 requests
                                                                                                                  Completed 30000 requests
                                                                                                                  Completed 40000 requests
                                                                                                                  Completed 50000 requests
                                                                                                                  Completed 60000 requests
                                                                                                                  Completed 70000 requests
                                                                                                                  Completed 80000 requests
                                                                                                                  Completed 90000 requests
                                                                                                                  Completed 100000 requests
                                                                                                                  Finished 100000 requests
                                                                                                                  
                                                                                                                  Server Software:        
                                                                                                                  Server Hostname:        localhost
                                                                                                                  Server Port:            8081
                                                                                                                  
                                                                                                                  Document Path:          /
                                                                                                                  Document Length:        11 bytes
                                                                                                                  
                                                                                                                  Concurrency Level:      16
                                                                                                                  Time taken for tests:   6.167 seconds
                                                                                                                  Complete requests:      100000
                                                                                                                  Failed requests:        0
                                                                                                                  Keep-Alive requests:    100000
                                                                                                                  Total transferred:      13700000 bytes
                                                                                                                  HTML transferred:       1100000 bytes
                                                                                                                  Requests per second:    16215.09 [#/sec] (mean)
                                                                                                                  Time per request:       0.987 [ms] (mean)
                                                                                                                  Time per request:       0.062 [ms] (mean, across all concurrent requests)
                                                                                                                  Transfer rate:          2169.40 [Kbytes/sec] received
                                                                                                                  
                                                                                                                  Connection Times (ms)
                                                                                                                                min  mean[+/-sd] median   max
                                                                                                                  Connect:        0    0   0.0      0       0
                                                                                                                  Processing:     1    1   0.1      1       3
                                                                                                                  Waiting:        1    1   0.1      1       3
                                                                                                                  Total:          1    1   0.1      1       3
                                                                                                                  
                                                                                                                  Percentage of the requests served within a certain time (ms)
                                                                                                                    50%      1
                                                                                                                    66%      1
                                                                                                                    75%      1
                                                                                                                    80%      1
                                                                                                                    90%      1
                                                                                                                    95%      1
                                                                                                                    98%      1
                                                                                                                    99%      1
                                                                                                                   100%      3 (longest request)
                                                                                                                  

                                                                                                                  benchmark tomcat
                                                                                                                  ab -n 100000 -k -c 16 http://localhost:8080/
                                                                                                                  This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
                                                                                                                  Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
                                                                                                                  Licensed to The Apache Software Foundation, http://www.apache.org/
                                                                                                                  
                                                                                                                  Benchmarking localhost (be patient)
                                                                                                                  Completed 10000 requests
                                                                                                                  Completed 20000 requests
                                                                                                                  Completed 30000 requests
                                                                                                                  Completed 40000 requests
                                                                                                                  Completed 50000 requests
                                                                                                                  Completed 60000 requests
                                                                                                                  Completed 70000 requests
                                                                                                                  Completed 80000 requests
                                                                                                                  Completed 90000 requests
                                                                                                                  Completed 100000 requests
                                                                                                                  Finished 100000 requests
                                                                                                                  
                                                                                                                  Server Software:        Apache-Coyote/1.1
                                                                                                                  Server Hostname:        localhost
                                                                                                                  Server Port:            8080
                                                                                                                  
                                                                                                                  Document Path:          /
                                                                                                                  Document Length:        12 bytes
                                                                                                                  
                                                                                                                  Concurrency Level:      16
                                                                                                                  Time taken for tests:   2.175 seconds
                                                                                                                  Complete requests:      100000
                                                                                                                  Failed requests:        0
                                                                                                                  Keep-Alive requests:    99008
                                                                                                                  Total transferred:      18395040 bytes
                                                                                                                  HTML transferred:       1200000 bytes
                                                                                                                  Requests per second:    45967.73 [#/sec] (mean)
                                                                                                                  Time per request:       0.348 [ms] (mean)
                                                                                                                  Time per request:       0.022 [ms] (mean, across all concurrent requests)
                                                                                                                  Transfer rate:          8257.60 [Kbytes/sec] received
                                                                                                                  
                                                                                                                  Connection Times (ms)
                                                                                                                                min  mean[+/-sd] median   max
                                                                                                                  Connect:        0    0   0.0      0       1
                                                                                                                  Processing:     0    0   0.4      0      11
                                                                                                                  Waiting:        0    0   0.4      0      11
                                                                                                                  Total:          0    0   0.4      0      11
                                                                                                                  
                                                                                                                  Percentage of the requests served within a certain time (ms)
                                                                                                                    50%      0
                                                                                                                    66%      0
                                                                                                                    75%      0
                                                                                                                    80%      0
                                                                                                                    90%      1
                                                                                                                    95%      1
                                                                                                                    98%      1
                                                                                                                    99%      2
                                                                                                                   100%     11 (longest request)
                                                                                                                  
                                                                                                                  • UFO just landed and posted this here
                                                                                                                      –1

                                                                                                                      30k rps, томкат еще медленный довольно, могу запустить в своем хттп-сервере в один поток, будет примерно 150к

                                                                                                                      • UFO just landed and posted this here
                                                                                                                          0
                                                                                                                          node
                                                                                                                          ab -n 1000000 -k -c 16 http://localhost:8081/
                                                                                                                          This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
                                                                                                                          Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
                                                                                                                          Licensed to The Apache Software Foundation, http://www.apache.org/
                                                                                                                          
                                                                                                                          Benchmarking localhost (be patient)
                                                                                                                          Completed 100000 requests
                                                                                                                          Completed 200000 requests
                                                                                                                          Completed 300000 requests
                                                                                                                          Completed 400000 requests
                                                                                                                          Completed 500000 requests
                                                                                                                          Completed 600000 requests
                                                                                                                          Completed 700000 requests
                                                                                                                          Completed 800000 requests
                                                                                                                          Completed 900000 requests
                                                                                                                          Completed 1000000 requests
                                                                                                                          Finished 1000000 requests
                                                                                                                          
                                                                                                                          Server Software:        
                                                                                                                          Server Hostname:        localhost
                                                                                                                          Server Port:            8081
                                                                                                                          
                                                                                                                          Document Path:          /
                                                                                                                          Document Length:        11 bytes
                                                                                                                          
                                                                                                                          Concurrency Level:      16
                                                                                                                          Time taken for tests:   32.601 seconds
                                                                                                                          Complete requests:      1000000
                                                                                                                          Failed requests:        0
                                                                                                                          Keep-Alive requests:    1000000
                                                                                                                          Total transferred:      137000000 bytes
                                                                                                                          HTML transferred:       11000000 bytes
                                                                                                                          Requests per second:    30673.57 [#/sec] (mean)
                                                                                                                          Time per request:       0.522 [ms] (mean)
                                                                                                                          Time per request:       0.033 [ms] (mean, across all concurrent requests)
                                                                                                                          Transfer rate:          4103.79 [Kbytes/sec] received
                                                                                                                          
                                                                                                                          Connection Times (ms)
                                                                                                                                        min  mean[+/-sd] median   max
                                                                                                                          Connect:        0    0   0.0      0       2
                                                                                                                          Processing:     0    1   0.8      0      19
                                                                                                                          Waiting:        0    0   0.8      0      19
                                                                                                                          Total:          0    1   0.8      0      20
                                                                                                                          WARNING: The median and mean for the processing time are not within a normal deviation
                                                                                                                                  These results are probably not that reliable.
                                                                                                                          WARNING: The median and mean for the total time are not within a normal deviation
                                                                                                                                  These results are probably not that reliable.
                                                                                                                          
                                                                                                                          Percentage of the requests served within a certain time (ms)
                                                                                                                            50%      0
                                                                                                                            66%      0
                                                                                                                            75%      1
                                                                                                                            80%      1
                                                                                                                            90%      1
                                                                                                                            95%      1
                                                                                                                            98%      3
                                                                                                                            99%      5
                                                                                                                           100%     20 (longest request)
                                                                                                                          

                                                                                                                          tomcat
                                                                                                                          ab -n 1000000 -k -c 16 http://localhost:8080/
                                                                                                                          This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
                                                                                                                          Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
                                                                                                                          Licensed to The Apache Software Foundation, http://www.apache.org/
                                                                                                                          
                                                                                                                          Benchmarking localhost (be patient)
                                                                                                                          Completed 100000 requests
                                                                                                                          Completed 200000 requests
                                                                                                                          Completed 300000 requests
                                                                                                                          Completed 400000 requests
                                                                                                                          Completed 500000 requests
                                                                                                                          Completed 600000 requests
                                                                                                                          Completed 700000 requests
                                                                                                                          Completed 800000 requests
                                                                                                                          Completed 900000 requests
                                                                                                                          Completed 1000000 requests
                                                                                                                          Finished 1000000 requests
                                                                                                                          
                                                                                                                          Server Software:        Apache-Coyote/1.1
                                                                                                                          Server Hostname:        localhost
                                                                                                                          Server Port:            8080
                                                                                                                          
                                                                                                                          Document Path:          /
                                                                                                                          Document Length:        12 bytes
                                                                                                                          
                                                                                                                          Concurrency Level:      16
                                                                                                                          Time taken for tests:   22.190 seconds
                                                                                                                          Complete requests:      1000000
                                                                                                                          Failed requests:        0
                                                                                                                          Keep-Alive requests:    990006
                                                                                                                          Total transferred:      183950030 bytes
                                                                                                                          HTML transferred:       12000000 bytes
                                                                                                                          Requests per second:    45066.05 [#/sec] (mean)
                                                                                                                          Time per request:       0.355 [ms] (mean)
                                                                                                                          Time per request:       0.022 [ms] (mean, across all concurrent requests)
                                                                                                                          Transfer rate:          8095.61 [Kbytes/sec] received
                                                                                                                          
                                                                                                                          Connection Times (ms)
                                                                                                                                        min  mean[+/-sd] median   max
                                                                                                                          Connect:        0    0   0.0      0       1
                                                                                                                          Processing:     0    0   3.4      0     808
                                                                                                                          Waiting:        0    0   3.3      0     808
                                                                                                                          Total:          0    0   3.4      0     808
                                                                                                                          
                                                                                                                          Percentage of the requests served within a certain time (ms)
                                                                                                                            50%      0
                                                                                                                            66%      0
                                                                                                                            75%      0
                                                                                                                            80%      0
                                                                                                                            90%      1
                                                                                                                            95%      1
                                                                                                                            98%      1
                                                                                                                            99%      1
                                                                                                                           100%    808 (longest request)
                                                                                                                          

                                                                                                                          мой кастомный сервер (1 поток)
                                                                                                                          ab -n 1000000 -k -c 16 http://localhost:10240/
                                                                                                                          This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
                                                                                                                          Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
                                                                                                                          Licensed to The Apache Software Foundation, http://www.apache.org/
                                                                                                                          
                                                                                                                          Benchmarking localhost (be patient)
                                                                                                                          Completed 100000 requests
                                                                                                                          Completed 200000 requests
                                                                                                                          Completed 300000 requests
                                                                                                                          Completed 400000 requests
                                                                                                                          Completed 500000 requests
                                                                                                                          Completed 600000 requests
                                                                                                                          Completed 700000 requests
                                                                                                                          Completed 800000 requests
                                                                                                                          Completed 900000 requests
                                                                                                                          Completed 1000000 requests
                                                                                                                          Finished 1000000 requests
                                                                                                                          
                                                                                                                          Server Software:        
                                                                                                                          Server Hostname:        localhost
                                                                                                                          Server Port:            10240
                                                                                                                          
                                                                                                                          Document Path:          /
                                                                                                                          Document Length:        11 bytes
                                                                                                                          
                                                                                                                          Concurrency Level:      16
                                                                                                                          Time taken for tests:   7.320 seconds
                                                                                                                          Complete requests:      1000000
                                                                                                                          Failed requests:        0
                                                                                                                          Keep-Alive requests:    1000000
                                                                                                                          Total transferred:      113000000 bytes
                                                                                                                          HTML transferred:       11000000 bytes
                                                                                                                          Requests per second:    136620.03 [#/sec] (mean)
                                                                                                                          Time per request:       0.117 [ms] (mean)
                                                                                                                          Time per request:       0.007 [ms] (mean, across all concurrent requests)
                                                                                                                          Transfer rate:          15076.23 [Kbytes/sec] received
                                                                                                                          
                                                                                                                          Connection Times (ms)
                                                                                                                                        min  mean[+/-sd] median   max
                                                                                                                          Connect:        0    0   0.0      0       1
                                                                                                                          Processing:     0    0   0.0      0       3
                                                                                                                          Waiting:        0    0   0.0      0       3
                                                                                                                          Total:          0    0   0.0      0       3
                                                                                                                          
                                                                                                                          Percentage of the requests served within a certain time (ms)
                                                                                                                            50%      0
                                                                                                                            66%      0
                                                                                                                            75%      0
                                                                                                                            80%      0
                                                                                                                            90%      0
                                                                                                                            95%      0
                                                                                                                            98%      0
                                                                                                                            99%      0
                                                                                                                           100%      3 (longest request)
                                                                                                                          
                                                                                                                          • UFO just landed and posted this here
                                                                                                                              0

                                                                                                                              нода у меня версии v5.3.0, в один поток 16к рпс, в режиме кластера — 30к, старенький томкат 7.0.55 — 45к, мой кастомный сервер — 136к рпс — сишный сокет-сервер, обернутый в jni, вся логика по обработке http написана на java. Запускал на ноутбуке с i7-3517U (2 ядра, 4 потока), java 1.8.0_92

                                                                                                                              • UFO just landed and posted this here
                                                                                                                                  0

                                                                                                                                  количество воркеров смогу проверить только вечером, но точно помню, что нода юзала все 4 потока, учитывая, что у проца всего два ядра, 30к — ожидаемый результат

                                                                                                                  0

                                                                                                                  1) Я не сравниваю Java и JS. Заведомо знаю, что JS быстрее за счёт нативных реализаций регулярных выражений. Сравнивать совместно с grossws начали Java и Python-.
                                                                                                                  2) Я не эксперт в прогревании Java, поэтому ниже Вы найдете комментарий, где я использовал правильное прогревание. Напишите свое прогревание, если это не понравится.
                                                                                                                  3) Обсуждение моей глупости предлагаю продолжить под этим комментарием.

                                                                                                                +2
                                                                                                                А почему node начинает тормозить, если exec делать не на константной строке, а например на text + i? Даже если создание строки вынести за пределы измерений. Не кешируется ли здесь результат?
                                                                                                                  +3

                                                                                                                  Не проверял детально, но тест на node может действительно работать быстрее, потому что регулярные выражения в js — это часть языка и написаны на Си, тогда как регулярные выражения в java — это часть стандартной библиотеки и написаны на java. Здесь вы по факту сравниваете Си с Java, причём разные по функциональности движки. Некоторые на эту тему уже возбуждались и даже статьи на хабр писали. Только даже в весьма спорной benchmarksgame это единственный тест, где node опережает джаву.

                                                                                                                  • UFO just landed and posted this here
                                                                                                                      +3

                                                                                                                      Java JIT (не GIT, конечно) не всесилен. Если вы не используете результат вызова, это не значит наверняка, что весь код будет выкошен JIT'ом. В Java regex-движке глубина вложенности очень велика и наверняка превышает дефолтный MaxInlineLevel (который равен 9), что не позволяет произвести полный анализ кода и убедиться, что он не производит побочных эффектов. Возможно, небольшая часть была удалена, но не всё. Разумеется, нормальный тест должен использовать результат.

                                                                                                                    +2
                                                                                                                    Если использовать не test, а test + " ", то js перестает быть таким быстрым:
                                                                                                                    JS:
                                                                                                                    RegExp#exec x 2,493,962 ops/sec ±0.80% (89 runs sampled)
                                                                                                                    RegExp#group() x 2,402,475 ops/sec ±2.65% (86 runs sampled)
                                                                                                                    RegExp#groupCount() x 2,532,103 ops/sec ±0.56% (90 runs sampled)
                                                                                                                    RegExp#exec_const x 4,050,939 ops/sec ±1.41% (86 runs sampled)
                                                                                                                    

                                                                                                                    Заметьте разницу между exec и exec_const. И что вы измеряли?
                                                                                                                    Код теста: http://pastebin.com/EKWVMMij

                                                                                                                    Java:
                                                                                                                    Benchmark                        Mode  Cnt        Score       Error  Units
                                                                                                                    MyBenchmark.matcher_find        thrpt  200  2007337,736 ± 16724,723  ops/s
                                                                                                                    MyBenchmark.matcher_group       thrpt  200  2007109,860 ± 16036,447  ops/s
                                                                                                                    MyBenchmark.matcher_groupCount  thrpt  200  1983016,501 ± 20402,445  ops/s
                                                                                                                    MyBenchmark.matcher_matches     thrpt  200  1971119,468 ± 20284,521  ops/s
                                                                                                                    

                                                                                                                    Код теста: http://pastebin.com/yaN9vCJC

                                                                                                                    Разрыв между exec и find + group() (функционально аналогичные действия) не большой — ~25%.

                                                                                                                    Какие из этих цифр можно сделать вывод? Да только один: к бенчмаркам надо подходить ответственно. Лично я не уверен, что бенчмарки, написанные мной, корректны. Стоит для начала подать на вход большой набор случайных строк, а не одинаковую строку. Да и в качестве тестирующего фреймворка для JS я не уверен.
                                                                                                                    Зато я убедился, что ваши тесты не корректны.
                                                                                                                    +1

                                                                                                                    JFYI, стандартная re не поддерживает юникодные классы (всякие \p{Lu} и подобные), так что сравнивать её с куда более продвинутой библиотекой j.u.regex просто некорректно.

                                                                                                                      0

                                                                                                                      При чем здесь это вообще?
                                                                                                                      Какая разница какой набор возможностей PCRE поддерживает конкретная реализация? Если в Питоне есть поддержка рекурсии, а в Ява нет, то сравнивать не корректно?
                                                                                                                      Поясните свою мысль подробнее.

                                                                                                                        0

                                                                                                                        Извините, что заставил Вас долго ждать. Был занят по работе, к сожалению, поэтому просто читал, минимум комментировал.
                                                                                                                        Продолжим замеры производительности, только теперь усложним регулярное выражение: до этого я приводил самое простое и примитивное.
                                                                                                                        Итак.
                                                                                                                        Есть очень полезная методика создания регулярных выражений в которых надо реализовать множественные правила.
                                                                                                                        Например, логин может состоять из [a-zA-Z0-9_ ], при этом не может быть два раза подряд символ _, а также текст должен начинаться с [a-zA-Z] и не заканчиваться на [ _]. По указанной выше методике получим регулярное выражение:


                                                                                                                        ^(?!.*__)(?=[A-Za-z])[a-z A-Z0-9_]+(?<![ _])$

                                                                                                                        Применим его к тексту:


                                                                                                                        c             a                      b                      d

                                                                                                                        После прогревания Java вдвое медленнее, чем Питон.
                                                                                                                        Проверьте у себя и продолжим разговор, если Вы не против.

                                                                                                                          0

                                                                                                                          Оу, прикольно :) За весь этот спор мне слили 8 кармы.
                                                                                                                          Печально вести спор, когда может минусовать любой человек не понимающий сути вопроса :( Зря я это начал :(
                                                                                                                          Ладно, буду надеяться, что они минусовали карму за личные набросы, а не то, что я иду против системы. Будет мне наука :(

                                                                                                                            0

                                                                                                                            Тесты (сразу говорю- не нравится IDEone, копируйте на свою локальную машину. Чините Copy/Paste- у некоторых сломано)
                                                                                                                            Java с качественным многоступенчатым прогреванием от xhumanoid:
                                                                                                                            http://ideone.com/6JU2Ln
                                                                                                                            На IDEone не хватает времени на прогрев Java. Результат на моей машине в среднем: 850ms
                                                                                                                            Python без прогревания:
                                                                                                                            http://ideone.com/MDuGlk
                                                                                                                            Результат на моей машине в среднем 430ms.

                                                                                                                              +6
                                                                                                                              не пойму, что вы пытаетесь доказать

                                                                                                                              но по порядку:
                                                                                                                              1) там было написано МИНИМАЛЬНОЕ что нужно сделать, но до нормального бенчмарка код все равно недотягивает
                                                                                                                              2) java 490ms, python 330ms

                                                                                                                              но раз вы уже пошли до «сложных регулярных выражений» со ссылкой на вашу методику, то и тестируйте её, чего сразу и не прогнать конечный регексп написанный вами же?

                                                                                                                              у меня получилось:
                                                                                                                              java 855ms и python 750ms
                                                                                                                              и если сразу не было 2 раза, разрыв не то что в процентных числах, в абсолютных начал уменьшаться при росте общего времени выполнения

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

                                                                                                                              вот только java реализация написана на java
                                                                                                                              python реализация на сях и полный список веселья тут,

                                                                                                                              а уж если вам так сильно необходимы быстрые регулярные выражений, то возьмите jregex, эта «нехорошая библиотека» на первом regexp выдает 130ms и на втором сложном 290ms, что оставляет глубоко в оппе как стандартную реализацию java, так и python

                                                                                                                              итого имеем:
                                                                                                                              java(standart)/java(jregex)/python(re)
                                                                                                                              490ms/130ms/330ms
                                                                                                                              855ms/290ms/750ms

                                                                                                                              итого мы доказали: стандартная обертка питона быстрее стандартных реализаций java (разница от 15% до 50%), и в более чем 2 раза медленней оптимизированной java реализации

                                                                                                                              вывод: нужны быстрые регекспы, берешь не питон/java/js/непонятночто, а нормальную либу
                                                                                                                      0
                                                                                                                      даже не CPython

                                                                                                                      А что? Или и вы перепутали CPython с Cython?

                                                                                                                        0

                                                                                                                        Регулярно находятся люди, которые их путают. Или утверждают, что они используют ruby, а не MRI.

                                                                                                                          0

                                                                                                                          Как я понимаю- для избежания путаницы нужно писать не CPython, а Python ;)

                                                                                                                            +1

                                                                                                                            Python — язык, CPython, PyPy, IronPython, JPython — реализации, которые по разному жрут память и cpu, а также имеют существенно разный набор поддерживаемых библиотек. Тот же JPython, скорее всего, будет использовать java.uril.regex.Pattern.


                                                                                                                            Вещи типа RPython и Cython уже чуток в сторону экзотики.

                                                                                                                    –2

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

                                                                                                                      +1

                                                                                                                      Сначала стоит написать реальные тесты и проверить, что по функциональности python'овский re не отличается от j.u.r.Pattern, что, как я помню, не так. Иногда re настолько убог, что приходится использовать библиотеку regex.

                                                                                                                        +1
                                                                                                                        > Для меня очень важны регулярные выражения и их производительность. В Java они меня очень расстраивают.

                                                                                                                        Для решения каких задач вы используете регулярные выражения?
                                                                                                                        Вы уверены, что это оптимальный инструмент для ваших задач?
                                                                                                                          0

                                                                                                                          Для задач парсинга текста.
                                                                                                                          Конечно оптимальный. Ведь если грамотно использовать регулярные выражения, то они более производительны, чем «чистые» реализации практически во всех транслируемых ЯП.
                                                                                                                          Дабы не спровоцировать спор еще и по этому вопросу сразу сделаю отсылку: https://habrahabr.ru/company/rootwelt/blog/302364/#comment_9647414

                                                                                                                          –3
                                                                                                                          Вспомнился старый сарказм:

                                                                                                                          Если Apple выпустит автомобиль, то он будет иметь инопланетный дизайн, удобный салон с одной кнопкой и будет уметь ездить только по прямой, а поклонники Apple будут удивляться «А зачем вообще куда-то поворачивать?».

                                                                                                                          Так же, скорее всего, и тут: А зачем нам регулярки на Java? Есть и другие способы парсинга.
                                                                                                                            –2

                                                                                                                            Например?
                                                                                                                            Напишите, пожалуйста, альтернативу str.replaceAll( "[^\wа-яА-ЯёЁ]+", "" )

                                                                                                                              –2
                                                                                                                              Возможно Вы меня спутали с противником регулярок. Я их активно использую в работе. К тому же, я на C/C++ чаще работаю.

                                                                                                                              Впрочем, парсить можно и на рекурсиях с математикой вокруг кодовой таблицы символов. Но на Java из-за отсутствия прямого доступа к памяти даже это будет работать медленнее.
                                                                                                                        +1

                                                                                                                        Если кого-то заинтересовало, что такое "gnu trove" (кстати, не имеет ни малейшего отношения к FSF), сразу смотрите сюда: http://java-performance.info/hashmap-overview-jdk-fastutil-goldman-sachs-hppc-koloboke-trove-january-2015/

                                                                                                                          0
                                                                                                                          У C++ есть свои проблемы с производительностью, делающие его медленнее, чем Java, на целом классе задач. Вот что сходу вспомнил:

                                                                                                                          1. Если вы аллоцируете много объектов (а сложное приложение аллоцирует много объектов), то в C++ запускается malloc, работающий сравнительно медленно. В GC аллокатор — это просто инкремент одного значения. Я писал свой игрушечный компилятор JVM в LLVM, и на первое время не написал свой аллокатор, а использовал malloc. Потом написал простецкий GC, и получил колоссальный прирост (от 2 до 5 раз) на различных задачах. Если бы я был отделом разработки Oracle, то я бы написал очень шустрый GC и всё стало бы работать ещё быстрее.
                                                                                                                          2. Если у вас сложный граф объектов, то в C++ придётся использовать smart pointers. Это дополнительный расход памяти и дополнительные расходы на инкремент/декремент счётчиков. Да, в GC есть write barriers, но они не пишут в память, т.е. они быстрее (и локальнее по памяти).
                                                                                                                          3. GC (особенно перемещающий) делает ваши данные в памяти более локальными. В C++ есть серьёзные проблемы с дефрагментацией кэша, с которой отчаянно пытается бороться malloc. Привет, CPU cache!
                                                                                                                          4. При использовании множественного наследования в C++ получается два негативных эффекта: увеличивается размер заголовка каждого экземпляра такого класса, появляется оверхед на операцию == в некоторых случаях. В Java такой проблемы нет, т.к. множественное наследование возможно только на интерфейсах, и поэтому оно реализуется гораздо эффективнее.
                                                                                                                          5. В C++ нет возможности заинлайнить функцию из одного модуля в функцию из другого (если только не используется clang и модули не распространяются в виде биткода). Я так понимаю, основная масса моего /usr/lib — это всё-таки не биткод LLVM.

                                                                                                                          Если вы пишете криптографию или видеокодек, то данные проблемы вас не касаются (правда, и C++ вас не касается, тут уже ближе к C с ассемблером). В сложных больших приложениях, вроде всякого энтерпрайза или IDE, всё это обычно встаёт в полный рост, и использовать Java предпочтительнее, именно с точки зрения производительности.
                                                                                                                            0
                                                                                                                            1. Если вы аллоцируете много объектов (а сложное приложение аллоцирует много объектов), то в C++ запускается malloc, работающий сравнительно медленно. В GC аллокатор — это просто инкремент одного значения.

                                                                                                                            И какого же? А разве GC не должен искать блок подходящего размера? Откуда он возьмёт сам указатель на выделяемый блок памяти?
                                                                                                                            Что касается дальнейшего описания — вы точно сделали настоящий, потокобезопасный GC? Потому что сравнивать потокобезопасный malloc и игрушечный GC без потокобезопасности как-то странно.
                                                                                                                            2. Если у вас сложный граф объектов, то в C++ придётся использовать smart pointers. Это дополнительный расход памяти и дополнительные расходы на инкремент/декремент счётчиков. Да, в GC есть write barriers, но они не пишут в память, т.е. они быстрее (и локальнее по памяти).

                                                                                                                            Может быть, имеются в виду shared pointers? Потому что в smart никаких счётчиков нет, ибо на один объект может быть только один указатель.
                                                                                                                            3. GC (особенно перемещающий) делает ваши данные в памяти более локальными. В C++ есть серьёзные проблемы с дефрагментацией кэша, с которой отчаянно пытается бороться malloc. Привет, CPU cache!

                                                                                                                            А как НЕперемещающий GC может сделать данные более локальными?
                                                                                                                            4. При использовании множественного наследования в C++ получается два негативных эффекта: увеличивается размер заголовка каждого экземпляра такого класса, появляется оверхед на операцию == в некоторых случаях. В Java такой проблемы нет, т.к. множественное наследование возможно только на интерфейсах, и поэтому оно реализуется гораздо эффективнее.

                                                                                                                            При множественном наследовании нет никакого оверхеда. Данные объектов идут один за другим в памяти (возможно, с выравниванием). Вы не путаете с виртуальным наследованием?
                                                                                                                            5. В C++ нет возможности заинлайнить функцию из одного модуля в функцию из другого (если только не используется clang и модули не распространяются в виде биткода). Я так понимаю, основная масса моего /usr/lib — это всё-таки не биткод LLVM.

                                                                                                                            Можно как минимум в Visual Studio 2012 (и позже). Но, естественно, только если транслируются исходники модулей — из dll ничего заинлайнить нельзя. Про gcc не в курсе.
                                                                                                                              +1
                                                                                                                              И какого же? А разве GC не должен искать блок подходящего размера? Откуда он возьмёт сам указатель на выделяемый блок памяти?

                                                                                                                              Не должен. Получить значение очередного блока памяти — это просто инкремент. Даже проверять, что память исчерпана не надо — вместо этого можно просто сделать trap на segfault.


                                                                                                                              Что касается дальнейшего описания — вы точно сделали настоящий, потокобезопасный GC?

                                                                                                                              Нет, GC непотокобезопасный, неинкрементальный, и вообще очень тупой. Однако, это не относится к теме. Я на различных бенчмарках гонял реализацию на malloc, и на gc_alloc, и тормоза были (как показал мне gprof) именно на вызовах malloc. Прирост был не за счёт освобождения памяти, а за счёт аллоцирования (кстати, в своём GC я сделал оптимизацию, которая умеет освобождать неиспользуемые объекты сразу большими группами, если они расположены друг за другом, привет free).


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


                                                                                                                              1. Сделал многопоточный аллокатор. Врочем, там один только инкремент — т.е. он уже многопоточный.
                                                                                                                              2. Реализовал бы safe points, научил бы GC ждать, когда все потоки дойдут до safe points. Это очень даже небольшой оверхед, особенно если грамотно расставлять эти самые safe points.
                                                                                                                              3. Т.к. у меня GC и так простейший и тупейший, ну ok, я бы сделал, чтобы все потоки ждали, пока GC отработает, сам бы GC работает в один поток.

                                                                                                                              Может быть, имеются в виду shared pointers? Потому что в smart никаких счётчиков нет, ибо на один объект может быть только один указатель.

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


                                                                                                                              А как НЕперемещающий GC может сделать данные более локальными?

                                                                                                                              Никак, но в реализации JVM, о которой говорят в 95% случаев (т.е. от Oracle) GC перемещающий. Да в любой другой уважающей себя то же самое. Кроме, разве что, какой-нибудь кровавой эмбедщины.


                                                                                                                              При множественном наследовании нет никакого оверхеда. Данные объектов идут один за другим в памяти (возможно, с выравниванием). Вы не путаете с виртуальным наследованием?

                                                                                                                              Я не знаю, что такое виртуальное наследование. Я знаю, что для поддержки виртуальных вызовов используется механизм virtual tables. Так вот проблема в том, что у экземпляра класса, который наследуется от N других классов, будет N ссылок на virtual table. В Java есть свои сложности в реализации invokeinterface, но они решаются, причём без загаживания объекта списком vtableptr.


                                                                                                                              Можно как минимум в Visual Studio 2012 (и позже). Но, естественно, только если транслируются исходники модулей — из dll ничего заинлайнить нельзя. Про gcc не в курсе.

                                                                                                                              Можно в определённых средах, которые требуют особой упаковки библиотек. Не только VS, ещё и clang так может, если правильно собирать модули. Проблема в том, что в системе 100500+ имеющихся библиотек, которые уже упакованы в DLL или so.

                                                                                                                                +3
                                                                                                                                Получить значение очередного блока памяти — это просто инкремент.

                                                                                                                                Инкремент чего? Хотя бы в двух словах. А то я никак не могу себе представить выделение памяти одним инкрементом (даже без GC).

                                                                                                                                Нет, GC непотокобезопасный, неинкрементальный, и вообще очень тупой. Однако, это не относится к теме. Я на различных бенчмарках гонял реализацию на malloc, и на gc_alloc, и тормоза были (как показал мне gprof) именно на вызовах malloc.

                                                                                                                                То есть вы сравнили потоконебезопасный GC с malloc'ом, который, не исключено, бОльшую часть времени тратит именно на блокировку. Не очень справедливо. Можно и malloc сделать игрушечный, который будет настоящий обгонять.
                                                                                                                                Т.к. у меня GC и так простейший и тупейший, ну ok, я бы сделал, чтобы все потоки ждали, пока GC отработает, сам бы GC работает в один поток.

                                                                                                                                И стал бы он у вас, скорее всего, ещё медленнее malloc'а.

                                                                                                                                Я не знаю, что такое виртуальное наследование. Я знаю, что для поддержки виртуальных вызовов используется механизм virtual tables. Так вот проблема в том, что у экземпляра класса, который наследуется от N других классов, будет N ссылок на virtual table. В Java есть свои сложности в реализации invokeinterface, но они решаются, причём без загаживания объекта списком vtableptr.

                                                                                                                                А вот за это спасибо. Правда, пришлось самому искать, как это в Java реализовано, но нашёл. В общем, это полностью отдано на откуп JVM, и вполне может быть реализовано как на C++. Но, например, в Orcale'овской реализации сделано так: указатель на инстанцию объекта (включая, видимо, и this) — это, на самом деле, пара указателей: собственно указатель на данные, и указатель на описание класса (в котором есть указатели на методы). Поэтому JVM, имея такой указатель, может скастовать его к любому классу-предку или интерфейсу. Таким образом, увеличивается вдвое указатель, но уменьшается память под данные объекта. Жалко, что такое нельзя сделать для C++, т.к. иначе, видимо, поломается ABI старых C-шных либ.

                                                                                                                                Можно в определённых средах, которые требуют особой упаковки библиотек. Не только VS, ещё и clang так может, если правильно собирать модули. Проблема в том, что в системе 100500+ имеющихся библиотек, которые уже упакованы в DLL или so.

                                                                                                                                Ну тут, увы, непреодолимый недостаток бинарного кода. Тут байт-код, конечно, выигрывает (если JVM, конечно, поддерживает такой инлайнинг).
                                                                                                                                  +6
                                                                                                                                  Инкремент чего? Хотя бы в двух словах. А то я никак не могу себе представить выделение памяти одним инкрементом (даже без GC).

                                                                                                                                  Если говорить про hotspot (а в контексте современных oracle jvm логично предполагать его), то там используется хитрая иерархия аллокаторов. В younggen выделяются TLAB (thread local allocation buffer), через который реализуется fast-path выделения памяти простым увеличением указателя (что konsoletyper назвал инкрементом).


                                                                                                                                  По сути TLAB хранит значения: указатель на начало буфера start, указатель на начало незанятого фрагмента current, размер bufSize (или указатель на первый элемент после конца буфера end). Освобождения памяти в этом режиме нет вообще, выделение примерно такое:


                                                                                                                                  void *alloc(size_t size) {
                                                                                                                                    if (current + size > end) { // or current + size > start + bufSize
                                                                                                                                      return NULL;
                                                                                                                                    }
                                                                                                                                    void *result = current;
                                                                                                                                    current += size;
                                                                                                                                    return result;
                                                                                                                                  }

                                                                                                                                  Бонус в том, что все переменные — thread local и выделение не требует дорогой синхронизации, уменьшается contention на younggen'е. Когда tlab заканчивается может выделяться новый. Видел статью, где предлагалось использовать иерархию PLAB/CLAB/TLAB (processor-/core-/thread-local), но об успехах во внедрении в реальные системы не знаю.


                                                                                                                                  Этот подход нормально работает в managed языках с GC, т. к. при исчерпании места в TLAB'ах/younggen'е можно произвести minor gc и избавиться от фрагментации и уже мертвых объектов.

                                                                                                                                    0
                                                                                                                                    Инкремент чего? Хотя бы в двух словах. А то я никак не могу себе представить выделение памяти одним инкрементом (даже без GC).

                                                                                                                                    Как это объясняют «на пальцах» на курсах про java: вся память разбита на 2 равные части. используется только 1, заполняется последовательно (таки да, простым инкрементом указателя на конец заполненной части выделяется место под объект). Кончилась — составляется граф живых объектов, все живые копируются во вторую половину памяти, которая назначается рабочей. (Это упрощенное описание для молодого поколения с упущенной финализацией). Как вы можете заметить в данном описании больше половины памяти не используется. Это не верно для G1 (есть в java 8 и будет по умолчанию в java9). Про G1: https://youtu.be/iGRfyhE02lA

                                                                                                                                    Про виртуальные методы: JVM, если увидит, что чаще всего используется 1-2 реализации, вставит проверку на тип и не виртуальный вызов этих реализаций. Или вообще их заинлайнит. Про девиртуализацию и инлайнинг: https://youtu.be/Pc-aB5U7RBI?t=29m24s
                                                                                                                                      +2
                                                                                                                                      То есть вы сравнили потоконебезопасный GC с malloc'ом, который, не исключено, бОльшую часть времени тратит именно на блокировку. Не очень справедливо.

                                                                                                                                      Я всё расписал, читаем внимательно. Блокировкой такому тяжёлому аллокатору, как malloc, заниматься приходится. Хотя, возможно, есть неблокирующие реализации, я не знаю, до чего там техника дошла. Неблокирующий аллокатор для GC делается тривиально, ибо сам аллокатор в GC устроен чрезвычайно просто.


                                                                                                                                      И стал бы он у вас, скорее всего, ещё медленнее malloc'а.

                                                                                                                                      Неправда, потому что malloc занимается только выделением памяти, а не освобождением. В данном случае надо сравнивать скорость работы free и GC. Так вот про это я опять же всё написал: free освобождает объекты по одному, GC может освобождать сразу тысячи и даже миллионы объектов.


                                                                                                                                      В общем, это полностью отдано на откуп JVM, и вполне может быть реализовано как на C++.

                                                                                                                                      Разумеется, в Java всё отдано на откуп конкретной реализации JVM, как и в C++ всё отдано на откуп конкретной реализации компилятора. Мы говорим о практически хороших реализациях.


                                                                                                                                      Но, например, в Orcale'овской реализации сделано так: указатель на инстанцию объекта (включая, видимо, и this) — это, на самом деле, пара указателей: собственно указатель на данные, и указатель на описание класса (в котором есть указатели на методы)

                                                                                                                                      Странная у вас информация. В HotSpot указатель — это такой же указатель, как в C++ (ну или в случае 64-битной архитектуры и включённого compressed oops — (int) (указатель >> 3)). Другое дело, что первые 8 или 16 байт объекта отводится под заголовок, в котором, в числе прочего, есть ссылка на класс, который содержит так же и virtual table. Это нужно, чтобы правильно делать invokevirtual. Для реализации invokeinterface используются различные интересные методики, но им опять же хватает одной ссылки на класс из заголовка.


                                                                                                                                      В C++ ровно та же история: первые 4/8 байт у обычного объекта — это vtable_ptr. А вот у объекта с multiple inheritance должно быть n таких vtable_ptr (соответственно, 4/8 * n байт оверхеда).


                                                                                                                                      Жалко, что такое нельзя сделать для C++, т.к. иначе, видимо, поломается ABI старых C-шных либ.

                                                                                                                                      Дело не в том, что поломается ABI, а в том, что по-другому просто нельзя (или можно, но будет ещё больший оверхед по памяти или по производительности).


                                                                                                                                      (если JVM, конечно, поддерживает такой инлайнинг).

                                                                                                                                      Вот откуда идут все утверждения по поводу тормознутости Java. Люди просто не знают, каковы возможности C2 в HotSpot, и не желают знать.

                                                                                                                                        +1
                                                                                                                                        включённого compressed oops — (int) (указатель >> 3)

                                                                                                                                        Может быть и не 3, оно вполне тюнится.