Это появилось на канале ZA Tech в группе Slack несколько недель назад. Во время некоторых выступлений по Clojure спикеры делали такое замечание снова и снова.
По этому поводу я выступил в Slack. Теперь запишу для более широкого чтения и обсуждения.
Предисловие
Я тоже раньше думал, что JVM тяжёлая. Это было в начале 2000-х, в сравнении с PHP. Там были и другие тяжеловесы, вроде .NET и ColdFusion. Были и более лёгкие альтернативы вроде Perl и Python, но я тогда сидел на Windows, так что ActivePerl и ActivePython тоже были несколько тяжеловаты.
Впервые я преодолел свой «страх» перед JVM, когда развернул небольшое производственное приложение JRuby на Heroku. Этот маленький монстрик должен был выполнять только одну задачу в день. Он генерировал ряд PDF'ов, потом загружал их на iSign (сейчас не функционирует) для хранения и распространения. Сам iSign был классическим приложением Rails, которое хостилось на трёх AMI. Этот маленький динозавр на стоковом JVM (за исключением
-server -Xmx=512M) производил PDF'ки так быстро, что он буквально убивал трёхнодовый кластер при каждом запуске.Я по-прежнему думал, что он немного тяжеловат в работе, но влюбился в этого гадкого утёнка.
Я более-менее следил за событиями в разработке JRuby и историями успеха и замечательно провёл время на Rubyfuza 2015 с Чарльзом Наттером. Это меня настолько вдохновило, что я стал открывать пулл-реквесты в проектах Ruby, которые просто запускают их тесты на JRuby. На том одном и закончил, к моему стыду.
И к 2016 году
В ноябре 2016 года я попытался с нуля написать приложение Rails. Впервые за несколько месяцев программировал на Ruby на своей машине. Обновление
brew upgrade врезалось в rbenv и поэтому выбросило все установленные версии Ruby, а я даже не заметил.Мне предстояла презентация по WebSockets на Jozi.rb.
В начале выступления хотелось поиграться с репозиторием React on Rails, просто для общего ощущения совместного использования React и Rails. Я уже пару месяцев использовал re-frame и был уверен, что смогу вытянуть его голым React'ом.
Поезд сошёл с рельсов, и очень зрелищно.
Для клонирования и запуска одного шаблонного приложения требовалось обновить XCode, обновить инструменты командной строки для XCode (в сумме более 6 ГБ), установить новую версию Ruby и Bundler, а затем связать инсталляцию в шаблонном приложении… Всё просто, верно? Как и у большинства приложений Rails, у этого шаблонного приложения где-то в графе зависимостей была зависимость от libv8, и только это прибавляет более 1 ГБ в размере.
Всё упражнение заняло несколько часов.
Поиграв с такой впечатляющей демонстрацией, я осознал, что работа превращается в бросание монетки. Поэтому решил лучше сделать фронтенд на Ember, ибо я знаю его, а времени не хватало.
Опять то же самое, нужно обновить nvm, установить приемлемую версию node, установить ember-cli, сгенерировать приложение и установить зависимости через npm и bower.
Я немного поигрался и признал своё поражение, а вместо этого поделился своим опытом с коллегами. Это было унизительно, по-настоящему унизительно. Я чувствовал себя чужаком в мире, частью которого был так долго.
Вернёмся к заявлению, что JVM тяжёлая.
Как будем взвешивать?
- Размер JDK при скачивании слишком большой?
- Он использует много ресурсов в работе?
- Библиотеки занимают много места на диске?
- Развёртывание слишком тяжёлое?
- Она затормаживает вас день ко дню?
Вот некоторые вопросы, которые помогают преодолеть наши эмоциональные барьеры насчёт JVM.
Так что давайте займёмся ими и посмотрим, что выйдет на самом деле.
Первоначальный объём действительно настолько велик?
Эта «тяжесть» JVM — чистый FUD, начиная с якобы большого объёма первоначальной установки. Вы сравниваете примерно 200 МБ скачивания JDK с примерно 15 МБ скачивания Node или Ruby. Но это только начало. И для Node, и для Ruby в системе нужен нужен компилятор C, только он один — сотни мегабайт. Хуже того, вероятно вам понадобится компилятор в продакшне!
Куча раздувающей нагрузки и для Node, и для Ruby прячется от вас такими маленькими последовательными шагами. Если вы остановитесь и посчитаете объём, не говоря уже о потраченном времени, то 200 МБ окажутся гораздо более оптимальным вариантом.
Даже не хочу начинать составлять инструкцию по сборке вашего собственного веб-комплекта, просто чтобы не переписывать его, как только выйдет новый инструмент.
JVM так тяжела в работе?
JVM быстра, это вероятно одна из самых быстрых сред из существующих. Со временем она просто становится всё быстрее и легче. Тысячи самых умных инженеров работают над её улучшением, а ещё больше внесли свой вклад за последний 21 год.
Здесь есть реальные потоки выполнения, поддержка многоядерности, её можно адски конфигурировать или просто оставить как есть. Единственной полезной вещью, которую вам вероятно стоит знать, это установки ограничений памяти для JVM, и тогда она покажет чудеса при работе с ограничениями этого окружения.
Развёртываете на Heroku?
java -server -Xmx512m beast.jar. Если этого недостаточно, то у вас вероятно есть деньги, чтобы заплатить кому-то за совет… Ой, ну или просто посмотреть на StackOverflow.Вот ключевая мысль, которую Чарльз и другие парни из сообщества JRuby продолжают продвигать. Без всяких телодвижений, ваши приложения наверняка будут работать быстрее и быстрее с каждым релизом JVM (независимо от прогресса JRuby).
Использование диска настолько большое?
Мне было интересно, и я посмотрел в папку
~/.m2, где за 9 месяцев разработки c Clojure накопилось 1010 МБ зависимостей. Даже гигабайта ещё нет.$ du -sh /usr/local/opt/rbenv/versions/2.3.3 ~/.nvm/versions/node/v6.9.1 ~/.m2
690M /usr/local/opt/rbenv/versions/2.3.3
232M /Users/kenneth/.nvm/versions/node/v6.9.1
1010M /Users/kenneth/.m2Установка Ruby снова свежая и соответствует базовым требованиям для ведения этого блога и Middleman (я там работаю над исправлением). Да, чтобы вести этот статичный блог и участвовать в разработке инструментов, на которых он работает, требуется почти 700 МБ места.
У Node установлены только ember, docpad и bower, и он более 200 МБ.
Развёртывание настолько грузное?
Вероятно, вы можете предсказать, о чём я буду говорить…
При сборке вы делаете единственный файл JAR. В нём есть всё для работы вашего приложения на любой платформе. Просто помещаете JAR где нужно и предоставляете JVM разбираться с ним.
Нет такого требования, чтобы приложение работало на каком-то массивном сервере приложений, можете очень легко связать с производительным HTTP-сервером прямо в JAR-файле. Парни из Node так делают, и из Ruby тоже, но как-то файлы JAR не могут оставаться сами по себе? Я тоже так думал…
Я, например, освобождён от необходимости запускать
apt-get install build-essentials в продакшне.День ото дня с JVM
У меня работает минимум пять процессов JVM на моём 2012 MacBook Pro с 8 ГБ памяти. Работают постоянно и каждый день. Я никогда не пробовал запустить пять приложений Rails одновременно.
Почему пять? Два для Datomic (сбор данных и консоль), один для наших API бэкенда и один для того фронтенда, с которым я работаю. Иногда в фоне также идут автоматические тесты. Уверен, сжатие памяти macOS наверняка тут помогает, потому что у значительной части этих процессов JVM должна быть загружены в память одни и те же байты.
Если бы вы сказали мне об этом 10 месяцев назад, я бы только посмеялся. Кто в здравом уме запустит 5 или более процессов JVM? Я мог бы отдать руку на отсечение, что я никогда так не сделаю.
О, а что же насчёт путей классов и всех остальных сумасшедших вещей? Они вообще вас не коснутся благодаря отличному инструментарию Clojure. Это та же причина, по которой вы используете npm или bundler и не мучаетесь с включением путей. Вы могли бы делать это, но тогда у вас вероятно другая проблема, которую вы не замечаете.
Радости REPL
Если бы мне пришлось непрерывно останавливать и запускать экземпляры JVM, я бы точно сошёл с ума. Это беспокоило меня насчёт JRuby в старые времена. К счастью, с Clojure и великолепным REPL приходится перезапускать экземпляр JVM только в редком случае, когда я действительно где-то крупно облажался. Здесь довольно хорошая защита от дурака. Figwheel днями работает без проблем.
Заключение
Будьте осторожны, оценивая JVM как объект. Оценивайте Java как язык во всех смыслах, но не смешивайте его с виртуальной машиной.
Я тоже раньше думал как вы. Я думал о JVM как о том бегемоте. К счастью, теперь я смог избавиться от этих ограничений и получил результат работы тысяч гигантов, поддерживающих её.
Ни в коем случае не считайте этот пост как знак «конца Node» или «конца Ruby». Воспринимайте как свежую перспективу. Если не можете перейти на JVM, хотя бы подумайте, как уменьшить раздутость в своём собственном мире.
Спасибо, что уделили мне своё время. Изучайте Clojure и пробуйте Simple Made Easy.
Комментарии (50)
x07
22.03.2017 15:31-2А где этот пункт?
Он использует много ресурсов в работе?
В этом абзацеJVM так тяжела в работе?
вода одна, и ни какой конкретики.
Где сравнение сколько ресурсов нужно ноде, ruby и jvm для обработки «тестового-нагрузочного» приложения? Подозреваю что JVM окажется тяжелее всех и цена сервера для него будет выше чем для других сред. А сравнение по весу файлов и количеству зависимостей это детский сад.
norguhtar
30.03.2017 14:46Вот когда я столкнулся с руби я был несколько обескуражен насколько оно больше жрет ресурсов чем java
azsx
22.03.2017 15:34Кто в здравом уме запустит 5 или более процессов JVM?
Не совсем понимаю. С какого-то момента в 2016 году java обычные приложения (БД, обработка текста, ввод и вывод на экран) стало возможно запускать более, чем 5 штук на одной машине?
Я сталкивался с ситуацией, когда несколько java программ в ubuntu i5 32 gb просто хоронили ПК по процессору.j_wayne
22.03.2017 16:40+6Деталей мало. Похоронить CPU можно на каком угодно языке. Может они что-то тяжелое все же делали?
azsx
22.03.2017 17:13-6По сути просто висели в процессах. Ну или простые анализаторы небольшого числа логов.
Почему не смогу указать детали, перед тем как учить java я старался найти вагон софта на java для дома и быта, чтобы посмотреть как оно там на платформе java. Запускал пачками. Да, переносимость среди ПК на современных ОС — отличная. Но несколько «редакторов» или подобных программ на java запущенных в разных процессах (разный софт) очень нагружали процессор.
В статье пишут, что теперь это не так, я просто хочу уточнить — это правда?
ps
Замечу здесь, чтобы не плодить комментарии.
«разогретое» приложение на Java порвет большинство конкурентов по параметру «кол-во обработанных запросов в секунду».
Несомненно, это моя неграмотность. Но если мне понадобится сделать сложные преобразования для 1 млрд строк разной длинны даже если изменения можно будет сделать stringbuilder'ом я лучше другой ЯП возьму, не java. А уж работа с чистым string проиграет почти всем языкам (кроме С#).j_wayne
22.03.2017 17:29+1Как-то уж совсем конкретно подходите) Лучше конечно сначала было бы замерить, но речь не о том.
Java на сервере мне нравится за:
а) легкость деплоя — поставил пакет java8, запустил java -jar… Об этом упоминается в статье. С руби, например все не так гладко… А с другой стороны, программе на голанг и пакеты не нужны) Один бинарник.
б) экосистема. Много зрелых библиотек с хорошей документацией.
Мне понадобилась реализация протокола CoAP, самой полной и проработанной оказалась реализация на Java. Экономия сил и времени. А 1 млрд строк за миллисекунды мне обрабатывать не надо) Мне бы быстрее сервер в строй ввести.
в) JVM языки. Мешает статика? Groovy, Kotlin, JRuby. У меня есть двуязычный проект Java + Groovy, практически бесшовно стыкуются. Правда, проникшись идеями тов. Егора Бугаенко, груви в последнее время выпиливаю… А вот для DSL самое то.
г) IDEA действительно хороша для Java (эх, если бы еще не некоторое количество глюков..)
д) какое-то время назад надо было написать незатейливый, но кроссплатформенный десктопный клиент.
Проще всего мне было написать на Java FX. Скорее всего это только из-за того, что я знаком с Java.azsx
22.03.2017 18:19-1j_wayne мне так то всё равно, просто любопытно, почему настолько регулярно последние годы появляются статьи с одним содержанием «недавно java была совсем дохленькая, а теперь огогого зверь, всех рвёт». В очередном переводе автор пишет, что раньше никому в голову бы не пришло запускать 5 разных программ на java одновременно, а теперь легко. Это правда? Вы юзаете более 5 программ java на своем Пк одновременно?
а и б) Имею негативный опыт работы с российским софтом на java. Пара десятков страниц просто про подготовку системы, некоторые подводные камни (например, скопировать в определенный каталог в java home несколько файлов, требование установки именно определенной редакции java (даже не версии).
в) Согласен, была бы в php явная сильная статика (правда это уже не php).
г) Для меня это минус, когда для написания программ крайне желательна ide.
д) Согласен, я также однажды написал не на lazarus, а на netbeans с swing'ом (писал именно в ide, так как в блокноте бы не смог). Радует кроссплатформенность, но… Вот используется в организации софт на java, который давно уже настроили на java 6 и никто ради вас менять версию java не будет. Насколько хороша обратная совместимость в java?j_wayne
22.03.2017 18:43+1Про десктопный софт на своем ПК ничего путного сказать не могу. Кроме IDE не использую.
Та единственная десктопная программа, которую я поставлял клиенту, полностью самодостаточна, содержит embedded jre. Просто зазипованная папка, распаковать и запустить.
IDE vs VIM vs emacs vs whatsoever — спор неблагодарный и бесполезный, да. Для руби я использую текстовый редактор (ide лишь раздражает), для явы мне удобнее IDE.
Обратная совместимость есть. Сравнить особо не с чем. Слышал что у .NET с этим проблемы.
По поводу статей. Прогресс действительно есть, со временем совершенствуются GC, JIT-компилятор.
Когда я свитчнулся на руби, то слышал просто огромное количество критики от людей, которые с явой никогда не имели дело, кроме запуска каких нибудь чужих кривых десктопных программ. При этом у Ruby в то время были гораздо большие проблемы с производительностью, да и Ruby VM тоже имет GC (куда более простенький и гораздо менее настраиваемый) и склонность пожирать память. Просто CRUD-овые вебаппы ее много не едят, в принципе. Был опыт, когда нужна была обработка большого количества сильно связанных сущностей, rake таск на руби потреблял память сотнями МБ в сек.
Еще момент, яву все же нужно уметь готовить. Если бы большинство тех самых кривопрограмм ограничили heap до какого то приемлемого объема и настроили heap ratio так, чтобы jvm возвращала освобожденную память системе, возможно не было бы такой репутации, что ява требует ОЧЕНЬ много памяти. Впрочем, конечному пользователю это не очень интересно. Да и десктопный софт как явление помирает, чего его пинать лишний раз.
AndreyRubankov
23.03.2017 12:26В очередном переводе автор пишет, что раньше никому в голову бы не пришло запускать 5 разных программ на java одновременно, а теперь легко. Это правда? Вы юзаете более 5 программ java на своем Пк одновременно?
С приходом микросервисов порою необходимо подымать и больше 5 серверов, а еще IDE в несколько окон и дополнительные тулы. Конечно для комфортной работы в этом случае нужно порядка 16 Gb RAM, но больше всего съедает IDE; на микросервисы хватает по 200 мб, как на пару вкладок браузера :-)
А раньше этого не делали потому, что раньше более востребованным был подход с аппликешен контейнерами, когда в один контейнер запихивали и десять серверов. И запускать несколько таких контейнеров было действительно странным решением. Нужно было только в случае настройки/отладки кластеризации на уровне контейнера (к примеру shared-session между несколькими Tomcat инстансами).
UbuRus
22.03.2017 19:16+1А я сталкиваюсь с ситуацией когда приложение на ноде в одном процессе выжирает всю память из падает с OOM. Зато приложение на undertow и caeynne обрабатывает тысячи запросов и потребляет десятки мегабайт памяти.
Scf
22.03.2017 16:24Автор и правда немного передергивает факты.
- Java требует много памяти. Ну, в 2017 году может это уже и не так много, но совершающий полезную работу java процесс легче 300Мб RAM найти непросто
- Java приложения медленно стартуют и выходят на пиковое быстродействие не сразу
- Если вы измеряете время отклика java приложения в долях миллисекунд, придется оптимизировать настройки JVM
НО:
- "разогретое" приложение на Java порвет большинство конкурентов по параметру "кол-во обработанных запросов в секунду". Избыток памяти используется для экономии CPU.
- приложение — это файл или каталог с файлами. Из внешних зависимостей требуется только JRE
- переход на новую версию java почти всегда беспроблемный
Т.е. получаем идеальное решение для сервера, если есть память. И не очень хорошее решение для гуев.
UbuRus
22.03.2017 19:23+6О как можно обобщить всю экосистему до трех пунктов описывающих её. От 300мб, это какое-то наследие апликейшен серверов и спринга, не более.
Java приложения медленно стартуют и выходят на пиковое быстродействие не сразу
Мое приложение на undertow и cayenne стартует ~1s.
Java требует много памяти. Ну, в 2017 году может это уже и не так много, но совершающий полезную работу java процесс легче 300Мб RAM найти непросто
Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).
Если вы измеряете время отклика java приложения в долях миллисекунд, придется оптимизировать настройки JVM
Говорят есть такие GC, которые совсем без задержек, например в azul такой есть, а еще есть новый shenandoah...В общем каждый раз когда говорят о джаве одно и тоже: берут худшие примеры в экосистемы джавы, и лучшие в своей.
А атом все еще тормозит сильнее чем idea, а webpack как запускался по 30-60 секунд (в зависимости от проекта), так и запускается.
Scf
22.03.2017 19:47-4Одна секунда — это много для десктопного приложения, качественный софт должен открываться сразу. В Java9 обещают модули и пока еще экспериментальную систему предкомпиляции модулей, посмотрим на результаты...
Scf
23.03.2017 08:26Три человека, которым нравится секундная задержка между кликом по ярлыку и появлением окна приложения?
sshikov
23.03.2017 09:25+3Вовсе не в этом дело. Что значит «должен открываться сразу»? Кому должен и почему? Софты — они разные бывают. Ожидания при открытии окна какой-нибудь 3D CAD или Фотошопа и окна vim — это совершенно разные вещи.
Если приложение при этом открывает еще и последний проект, или скажем как firefox — все открытые ранее страницы, то ни о какой секунде на старт не может быть и речи, вообще говоря. В лучшем случае вы увидите пустое окно, и какие-то признаки активности. И данные (из интернета) за секунду вам никто не предоставит.Scf
23.03.2017 09:51+1Не спорю, что это не возможно для больших приложений, но мало кто из нас пишет действительно большие приложения. А для типичного shareware в условиях очень жесткой конкуренции между десятком похожих программ время старта — очень важное преимущество.
Типичный пример — просмотрщик фотографий. Люди до сих пор любят ACDSee3 именно за очень быстрый старт.
И, кстати, я был бы очень рад, если бы смог запустить firefox за доли секунды, открыть новую вкладку и начать работу. А предыдущие пускай грузит где-то в фоне.
sshikov
23.03.2017 10:21Да дело даже не в размере — дело в шаблонах использования. Если вы открыли приложение, и работаете в нем день — то 30 секунд с утра вам до лампочки. Это просто разные классы приложений. Да, для автономных утилит типа просмотра фоток время старта важно. А тот же самый просмотр фоток в рамках файрфокса — это уже совсем другая картина, тут уже нет никакого времени старта вообще, потому что вы как-бы открываете много разных страниц, на каждой из которых много разных картинок, которые скачиваются из интернета с разной скоростью, в разном качестве, и показываются в разном масштабе, а то и с фильтрами.
И да, новое пустое окно (в моем случае хром) вполне открывается за секунду. Как впрочем и новое окно в IDEA для нового класса в программе.
AndreyRubankov
23.03.2017 09:55+2Потребляет под нагрузкой 200мб, но можно выставить лимит хоть 20 мб и оно будет работать (но хуже, очевидно).
Справедливости ради, стоит отметить, что вы забываете про Meta Space. Он будет отъедать память, пока она есть в системе (по необходимости), даже если выставить -Xmx. Метаспейс нужно ограничивать отдельно, и это минимум +50 мб на x64.
И да, на x64 при -Xmx20M с SerialGC (как самой легкой) JVM даже не подымится. Compact3 profile возможно поможет, но с этим еще не игрался.
Вот так и выходим на минимум 200-300 Мб для работы приложения. Но взвесив все достоинства и недостатки, будет очевидно, что это небольшая плата за всю мощь, которую предоставляет JVM как платформа.
NaHCO3
22.03.2017 17:55-3> Этот маленький динозавр на стоковом JVM (за исключением -server -Xmx=512M) производил PDF'ки так быстро, что он буквально убивал трёхнодовый кластер при каждом запуске.
Вы бы ещё на си попробовали пописать для сравнения. Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
> Размер JDK при скачивании слишком большой?
Конечно большой. И не надо передёргивать про необходимость gcc — у меня оно и без того стоит. И даже если вы исповедуете подход «каждому процессу по виртуальной машине» никто не мешает вам подключить общие зависимости как единый ro-диск.
> Он использует много ресурсов в работе?
Конечно. Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск. Вопрос памяти вы тактично опустили. Вопрос времени голого старта на hellow world тоже. Вопрос сколько жрёт стандартная библиотека, которая всегда должна быть загружена — тоже. Если java такая лёгкая, то почему скрипты пишут на питоне, а не на джаве?
> Развёртывание слишком тяжёлое?
Как скрипт напишешь, так и будет. Верно для всех случаев.
> Она затормаживает вас день ко дню?
Конечно. У меня на 8-гиговом ноуте не запускается больше трёх джав одновременно — память заканчивается. При этом вспоминаем, что джава не умеет освобождать память добровольно, и когда у меня фризится подсветка синтаксиса в редакторе, проще убить и перезапустить процесс. Впрочем, однажды я запустил целых пять джав и остался относительно доволен — выделенную, но неосвобождённую память хитрая ОС спрятала в своп и почти к нему не обращалась. Своп от третьих лиц круче встроенного GC, дожили!EviGL
22.03.2017 18:10+3>>Он работает быстро, но не освобождает память добровольно. Единственный вариант — периодический перезапуск.
Разве же это единственный вариант? Там в Java тонко настраивается стратегия работы GC: хочется памяти, делаем GC агрессивнее, процессор кушается больше, память кушается меньше.NaHCO3
22.03.2017 18:31Тебе надо заранее указать максимальный порог — и JVM под это будет подстраиваться. Но если ты работаешь с данными, ты не знаешь заранее, сколько именно тебе понадобится памяти, чтобы их обработать, и значит не можешь выставить лимита. А без выставления лимита gc будет расширять память пока ОС ему это позволяет вместо того, чтобы чистить старое. Такая вот узкая заточка под серверные нужды, где нагрузка хорошо прогнозируется и можно учесть ожидаемое потребление памяти
EviGL
22.03.2017 18:40+2С дефолтными настройками так, но это всё настраивается. Не только максимальный порог, но и на каком количестве занятой памяти и как часто запускать GC. Если переусердствовать, правда, возникнет другая проблема — слишком частые или длинные паузы на GC, либо слишком много процессора будет жрать на GC. Но не надо говорить, что альтернативы нет, там настраивается абсолютно всё. Можно даже сменить алгоритм GC полностью, там доступно несколько.
Scf
22.03.2017 19:49+3$ time java Hello Hello, World! real 0m0.075s user 0m0.072s sys 0m0.000s
И про память вы неправы — джава, во всяком случае, java8, умеет отдавать обратно неиспользуемую память. Другой вопрос, что если приложение написано криво и течет по памяти.
h31
22.03.2017 20:10При этом вспоминаем, что джава не умеет освобождать память добровольно
Хорошая статья на эту тему: http://www.stefankrause.net/wp/?p=14
Одна опция запуска — и Java начинает спокойно отдавать память системе.
sshikov
22.03.2017 20:41+4>почему скрипты пишут на питоне, а не на джаве?
Кто вам сказал? Я вот на груви пишу. И поверьте — в большинстве случаев код получается намного проще. Да и медленнее питона тоже надо постараться сделать.
sshikov
23.03.2017 09:26>Один человек попробовал и выяснил, что баш скрипты в 250 раз быстрее HADOOP.
Это был сарказм?NaHCO3
23.03.2017 12:58-1это было округление в большую сторону. На самом деле:
https://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
https://tproger.ru/translations/command-line-tools-can-be-235x-faster/sshikov
23.03.2017 13:08+2На самом деле статью писал дурак. Который вообще не понимает, что такое Hadoop, зачем и когда его нужно применять. Скока-скока там гигабайт данных? Почти четыре?
Ну так чувак, который данные, влезающие в память одного узла кластера (не на диск даже, а в память) пытается вообще обрабатывать при помощи MapReduce на кластере — у меня нет для него цензурного названия. И для такого бенчмарка тоже.
Hadoop — это если совсем по-простому, такая штука, которую применяют, если данные перестали влезать на диск одной машины. И когда никакие баш скрипты для обработки просто неприменимы вообще.EviGL
23.03.2017 14:28+2Ну в той статье в выводах как раз и написано «не будьте дураками и не используйте hadoop когда всё можно посчитать на одной машине». Но кое-кто умудрился прочитать ту статью и сделать для себя вывод «баш скрипты быстрее hadoop» :)
sshikov
23.03.2017 16:38Не, ну не совсем. Там еще вот такое:
but more often than not these days I see Hadoop used where a traditional relational database or other solutions would be far better in terms of performance, cost of implementation, and ongoing maintenance.
Это можно на русский перевести примерно так: а еще я часто вижу, как сегодня гвозди забивают шуруповертами. Не делайте так, забивайте молотком. Все-таки статья желтовата. Этот вывод — он очевиден почти с самого начала, когда объемы данных огласили.
NaHCO3
23.03.2017 17:49-1> сделать для себя вывод «баш скрипты быстрее hadoop» :)
Но ведь автор оригинального послания поступил точно также — нашёл какую-то одну специфическую задачу генерации pdf, где джава была быстрее руби и сказал, что RoR не нужно.
Pro-invader
22.03.2017 19:56Про 5 приложений хочу отметить, что сын у меня играл в майнкрафт и игра у него сворачивалась, а он все время заново запускал.В итоге запустил штук шесть экземпляров и ничего, все работало! 8гб, AMD Phenom x2
rustler2000
23.03.2017 00:29-3А для чего ноде компайлер? И для чего ноде компайлер в продакшене?
А как же девы на венде? Мингв качают?
За перевод спасибо.
Scf
23.03.2017 08:25+1некоторые модули, которые ставятся через npm, содержат нативный код
https://github.com/nodejs/node-gyprustler2000
23.03.2017 14:08-1Ну да — и много вы знаете модулей которые требуют нативного кода? Я несколько и они крайне спецефичные (не считая разве что сислога, и то который можно без нативного кода сделать).
Сборка же на продакшене — это, пардон, рукожопство и полный игнор на CI\CD раз среды дев и прод так сильно различаются, что деплой требует сборки прямо вот на продакшене (не считая того что тянуть не нужные зависимости — оригинальный автор бы еще эклипс в продашкет ставил бы).Scf
23.03.2017 14:14Две основные причины:
- быстродействие
- использование нативных библиотек. Всё переписывать на яваскрипт не всегда хорошая идея
Nakosika
23.03.2017 11:27+1Так все андроид приложения на почти-яве. И ничего. Просто надо зависимости с умом выбирать, а не фреймворки типа все включено. Среднее приложение на андроиде всего в полтора раза тяжелее такого же на айос (там си почти что), при том бОльшую часть занимают ресурсы а не код.
Siemargl
25.03.2017 02:15-2Java жрать меньше не стала, просто с законом Мура 1Гб памяти на утилитку теперь можно назвать «JVM не такая тяжёлая» =)
Чистой воды Окна Овертона.
Следующей статьей полагается утверждать, что если ваше приложение потребляет менее 1Гб, то это моветон!m52
25.03.2017 09:52+2Скорее так: java сколько жрала, столько и жрет, просто аппетиты других программ и инструментов стали гораздо больше и на их фоне java не настолько и прожорливая. Ну и памяти стало больше, да.
j_wayne
30.03.2017 09:03Именно. Тот же Electron — минимальный апп 100+ Мб и ничего, не хают…
Репутация — страшная все таки штука.
Pro-invader
25.03.2017 16:54+1Тут Вам удобство и скорость разработки, а также кроссплатформенность, очень быстрая виртуальная машина и Вы хотите, чтобы приложения жрали немногим больше, чем на C?
Насчет «утилитки», то запущенная Idea на x64 всего 400Мб.
shybovycha
Насколько я помню, обновлять/устанавливать сам XCode не обязательно — достаточно наличия XCode Command Line Tools. А они, в свою очередь, занимают аж 158 МБ (пруф). Основную массу и у рубей, и у ноды, и у иных составляют именно что зависимости.