Недоволен скоростью джаваскриптов? — Подожди год-полтора, и это пройдёт!

    Напоминаю (потому что это наверняка подзабылось), что 22 мая 2012 года я экспериментировал с чтением заголовков фидонетовской эхопочты (хранимой в формате JAM) при помощи собственного модуля, сочинённого для Node.js (на основе подвернувшегося движка jParser, документацию по которому перевёл чуть раньше).

    Тогда, прогоняя тестовое чтение на одноядерном Pentium IV (2,2 ГГц), я остался недовольным скоростью: требовалось три-четыре секунды на то, чтобы считать 8222 заголовков из архива всего одной эхоконференции, ведущегося с марта 2007 года.

    На нынешней неделе у меня снова дошли руки до исходного кода того модуля; и я начал с того, что перенёс прежний тест на движок Mocha и передал тестирование на сервер Travis CI, указав в файле .travis.yml такие настройки, которые обеспечивали бы тестирование на трёх последовательных версиях движка Node.js — на 0.6, на 0.8 и на 0.10.

    Оказалось, что разница в скорости видна невооружённым глазом:


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

    На самом деле, конечно же, результат свидетельствует только о том, что в версии Node 0.8 тест срабатывает примерно в полтора раза быстрее, чем в предыдущей версии (0.6), а в версии Node 0.10 — даже в два раза быстрее, чем в предыдущей (0.8).

    Но и то неплохо.

    Кроме того, нынешней весною я себе приобрёл более новый компьютер на основе четырёхъядерного процессора i7-3770, и на нём тот же тест занимает время ещё меньшее — оно ближе к половине секунды, чем к целой секунде:

    [скриншот]

    Оно и понятно: Travis-то ведь пользуется виртуальными машинами, а я реальною.

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

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

    Only registered users can participate in poll. Log in, please.

    Согласны ли вы с этим выводом?

    • 14.9%Да84
    • 30.9%Скорее да174
    • 19.9%Не уверен(а)112
    • 19.2%Скорее нет108
    • 15.1%Нет85

    Заранее интересны ли дальнейшие мои блогозаписи примерно на такую же тему?

    • 56.3%Да, пиши ещё о тестировании модулей Node при помощи Mocha192
    • 27.3%Нет, только не о тестировании модулей Node при помощи Mocha93
    • 34.9%Да, пиши ещё о сочинении модулей Node для Фидонета119
    • 43.7%Нет, только не о сочинении модулей Node для Фидонета149
    • –1
    • 10.5k
    • 8
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 8

      0
      Три раза перечитал последний абзац и не в курил.

      ИМХО

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

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

      В общем выжидать не стоит. Сегодня смартфоны «слабые», завтра другие устройства «слабые» могут появиться на рынке.
        0
        Моё рассуждение ограничено рамками движка Node.js, а ведь Node.js не существует для смартфонов.

        Я первый бы порадовался, кабы положение дел было противоположным, но покамест оно выглядит именно так — а те первые шаги по переносу Node.js на Android, о которых я упоминал на Хабрахабре 19 июня, либо ничем не окончились, либо плоды их находятся на экспериментальной стадии у горстки каких-нибудь наипервейших энтузиастов, которых нетрудно пересчитать на пальцах одного человека. (Не то о них чего-нибудь было бы слышно; а ведь пока что ничего, ничего не слышно ещё.)

        Положение дел вдругорядь окажется способным перемениться, когда на рынке появятся другие «слабые» устройства? Хорошо же; подождём, покуда не явятся — тогда и посмотрим пренепременно; тогда, но не раньше.
          0
          Ну я говорил обобщено, не только про Node.js. Похожие проблемы есть у всех языков, движков и т.д. Не важно на чем и для чего — похожая тенденция везде. Думаю каждый задавался подобными вопросами. Не спроста же продолжают наращивать производительность железа. Это было, есть и будет )))

          Я не работаю с Node.js, поэтому рассматриваю его просто как JS + браузеры, что в принципе он из себя и представляет. А вот такое уже есть на всех платформах.

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

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

          Да и самому приятнее, когда твоё творение работает быстрее, особенно быстрее конкурентов. Поэтому если есть возможности, то стоит потратить время на оптимизацию.

          Кстати, вполне обычная ситуацию, даже в контексте поста. Сегодня надо просто получить массово заголовки. Это занимает X секунд. Завтра встанет задача и надо будет их ещё и обработать. А на обработку каждого заголовка будет уходить Y секунд. То ту получится уже график как на картинке ниже Будет уже затрачено времени XY.
        +24
        > возникает соблазн видеть арифметическую прогрессию (три секунды → две секунды → одна секунда) с напрашивающимся выводом о том, что в следующей версии движка Node тест вообще станет срабатывать мгновенно
        Экстраполирование для чайников

        По теме — очевидно, что в некий момент оптимизационной составляющей можно будет пренебрегать ввиду вычислительных мощностей. Вопрос времени наступления сего — другая тема.
          +5
          При переходе 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%
          
            +1
              –4
              Конечно, джи пожалуйста, дай возможность нормальным парням которые поборов свою лень напишут на нормальном языке и обгонят тебя в 100 раз, займут нишу на рынке.
                0
                Такой подход можно еще назвать оптимизацией Quake — получаешь заказ чтобы программа работала в два раза быстрее, соглашаешься что сделаешь за полтора года, играешь в Quake все это время, и перед релизом меняешь железо — на выходе получается работа в два раза быстрее!!!

                Only users with full accounts can post comments. Log in, please.