Комментарии 8
Три раза перечитал последний абзац и не в курил.
ИМХО
— с нынешней тенденцией пользоваться громадными готовыми либами/плагинами/модулями/еtс
— с тенденциями к росту в приложениях функционала и красявостей
оптимизация приложений ради ускорения необходима, даже с учетом роста производительности железа и движков, типа V8.
А вот фанатичная оптимизация, оптимизация на последнем этапе или с самого начала — каждый должен решать для себя и опираться на свои возможности, ибо некоторые стремятся сразу писать оптимизировано, а некоторые сначала пишут «лишь бы работало» и только потом оптимизируют.
В общем выжидать не стоит. Сегодня смартфоны «слабые», завтра другие устройства «слабые» могут появиться на рынке.
ИМХО
— с нынешней тенденцией пользоваться громадными готовыми либами/плагинами/модулями/еtс
— с тенденциями к росту в приложениях функционала и красявостей
оптимизация приложений ради ускорения необходима, даже с учетом роста производительности железа и движков, типа V8.
А вот фанатичная оптимизация, оптимизация на последнем этапе или с самого начала — каждый должен решать для себя и опираться на свои возможности, ибо некоторые стремятся сразу писать оптимизировано, а некоторые сначала пишут «лишь бы работало» и только потом оптимизируют.
В общем выжидать не стоит. Сегодня смартфоны «слабые», завтра другие устройства «слабые» могут появиться на рынке.
Моё рассуждение ограничено рамками движка Node.js, а ведь Node.js не существует для смартфонов.
Я первый бы порадовался, кабы положение дел было противоположным, но покамест оно выглядит именно так — а те первые шаги по переносу Node.js на Android, о которых я упоминал на Хабрахабре 19 июня, либо ничем не окончились, либо плоды их находятся на экспериментальной стадии у горсткикаких-нибудь наипервейших энтузиастов, которых нетрудно пересчитать на пальцах одного человека. (Не то о них чего-нибудь было бы слышно; а ведь пока что ничего, ничего не слышно ещё.)
Положение дел вдругорядь окажется способным перемениться, когда на рынке появятся другие «слабые» устройства? Хорошо же; подождём, покуда не явятся — тогда и посмотрим пренепременно; тогда, но не раньше.
Я первый бы порадовался, кабы положение дел было противоположным, но покамест оно выглядит именно так — а те первые шаги по переносу Node.js на Android, о которых я упоминал на Хабрахабре 19 июня, либо ничем не окончились, либо плоды их находятся на экспериментальной стадии у горстки
Положение дел вдругорядь окажется способным перемениться, когда на рынке появятся другие «слабые» устройства? Хорошо же; подождём, покуда не явятся — тогда и посмотрим пренепременно; тогда, но не раньше.
Ну я говорил обобщено, не только про Node.js. Похожие проблемы есть у всех языков, движков и т.д. Не важно на чем и для чего — похожая тенденция везде. Думаю каждый задавался подобными вопросами. Не спроста же продолжают наращивать производительность железа. Это было, есть и будет )))
Я не работаю с Node.js, поэтому рассматриваю его просто как JS + браузеры, что в принципе он из себя и представляет. А вот такое уже есть на всех платформах.
Под «слабыми» я подразумевал планшеты, нетбуки, ТВ. Почему о последнем часто забывают, говоря о мобильном устройстве (а именно о мобильных я и говорил, надо было так и написать).
Завтра могут появиться массово тонкие гибкие дисплее, которые сейчас на выставках активно представляются, думаю там будут пытаться уменьшить всё что только можно. А может какие прожекторного или голографические типа штуки появятся и/или наберут популярность. Тут можно долго гадать чего же в ближайшее время выпустят на рынок и какой мощности эти штуки будут.
Да и самому приятнее, когда твоё творение работает быстрее, особенно быстрее конкурентов. Поэтому если есть возможности, то стоит потратить время на оптимизацию.
Кстати, вполне обычная ситуацию, даже в контексте поста. Сегодня надо просто получить массово заголовки. Это занимает X секунд. Завтра встанет задача и надо будет их ещё и обработать. А на обработку каждого заголовка будет уходить Y секунд. То ту получится уже график как на картинке ниже Будет уже затрачено времени XY.
Я не работаю с Node.js, поэтому рассматриваю его просто как JS + браузеры, что в принципе он из себя и представляет. А вот такое уже есть на всех платформах.
Под «слабыми» я подразумевал планшеты, нетбуки, ТВ. Почему о последнем часто забывают, говоря о мобильном устройстве (а именно о мобильных я и говорил, надо было так и написать).
Завтра могут появиться массово тонкие гибкие дисплее, которые сейчас на выставках активно представляются, думаю там будут пытаться уменьшить всё что только можно. А может какие прожекторного или голографические типа штуки появятся и/или наберут популярность. Тут можно долго гадать чего же в ближайшее время выпустят на рынок и какой мощности эти штуки будут.
Да и самому приятнее, когда твоё творение работает быстрее, особенно быстрее конкурентов. Поэтому если есть возможности, то стоит потратить время на оптимизацию.
Кстати, вполне обычная ситуацию, даже в контексте поста. Сегодня надо просто получить массово заголовки. Это занимает X секунд. Завтра встанет задача и надо будет их ещё и обработать. А на обработку каждого заголовка будет уходить Y секунд. То ту получится уже график как на картинке ниже Будет уже затрачено времени XY.
> возникает соблазн видеть арифметическую прогрессию (три секунды → две секунды → одна секунда) с напрашивающимся выводом о том, что в следующей версии движка Node тест вообще станет срабатывать мгновенно
По теме — очевидно, что в некий момент оптимизационной составляющей можно будет пренебрегать ввиду вычислительных мощностей. Вопрос времени наступления сего — другая тема.
По теме — очевидно, что в некий момент оптимизационной составляющей можно будет пренебрегать ввиду вычислительных мощностей. Вопрос времени наступления сего — другая тема.
При переходе 0.8->0.10 была улучшена производительность модулей, связанных с вводом-выводом. Как известно I/O самая медленная операция и поэтому буст в 1700% решает больше чем, чуть более быстрая молотилка цифр — те апгрейд V8. Так же был улучшен «алгоритм работы» nextTick() — что сильно бустануло все асинхронные операции и промисы.
fs/read-stream buf size=1024: v0.10: 1106.6 v0.8: 60.597 ................... 1726.12%
fs/write-stream buf size=1024: v0.10: 59.926 v0.8: 49.822 .................... 20.28%
tls/throughput.js dur=5 type=asc size=1024: v0.10: 199.7 v0.8: 102.46 ........ 94.91%
Конечно, джи пожалуйста, дай возможность нормальным парням которые поборов свою лень напишут на нормальном языке и обгонят тебя в 100 раз, займут нишу на рынке.
Такой подход можно еще назвать оптимизацией Quake — получаешь заказ чтобы программа работала в два раза быстрее, соглашаешься что сделаешь за полтора года, играешь в Quake все это время, и перед релизом меняешь железо — на выходе получается работа в два раза быстрее!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Недоволен скоростью джаваскриптов? — Подожди год-полтора, и это пройдёт!