Быстрый gzip на javascript для браузера и node.js

    Недавно появился проект pako, это порт на яваскрипт известной библиотеки для компрессии и декомпрессии данных — zlib.

    Очень любопытен результат тестов.

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

    node v0.10.26, 1mb sample:

    deflate-dankogai x 4.74 ops/sec ±0.68% (15 runs sampled)
    deflate-gildas x 4.61 ops/sec ±1.73% (15 runs sampled)
    deflate-imaya x 3.10 ops/sec ±3.73% (11 runs sampled)
    ! deflate-pako x 7.11 ops/sec ±0.26% (21 runs sampled)
    deflate-pako-untyped x 4.34 ops/sec ±1.35% (14 runs sampled)
    deflate-zlib x 14.34 ops/sec ±2.90% (68 runs sampled)
    inflate-dankogai x 31.29 ops/sec ±0.72% (56 runs sampled)
    inflate-imaya x 30.49 ops/sec ±0.84% (53 runs sampled)
    ! inflate-pako x 70.00 ops/sec ±1.60% (71 runs sampled)
    inflate-pako-untyped x 17.67 ops/sec ±1.27% (33 runs sampled)
    inflate-zlib x 70.82 ops/sec ±1.69% (81 runs sampled)


    node v0.11.11, 1mb sample:

    deflate-dankogai x 5.61 ops/sec ±0.30% (17 runs sampled)
    deflate-gildas x 4.97 ops/sec ±5.68% (16 runs sampled)
    deflate-imaya x 3.53 ops/sec ±4.19% (12 runs sampled)
    ! deflate-pako x 11.52 ops/sec ±0.23% (32 runs sampled)
    deflate-pako-untyped x 5.12 ops/sec ±1.44% (17 runs sampled)
    deflate-zlib x 14.33 ops/sec ±3.34% (63 runs sampled)
    inflate-dankogai x 42.96 ops/sec ±0.19% (57 runs sampled)
    inflate-imaya x 85.05 ops/sec ±1.07% (71 runs sampled)
    ! inflate-pako x 97.58 ops/sec ±0.69% (80 runs sampled)
    inflate-pako-untyped x 18.06 ops/sec ±0.65% (56 runs sampled)
    inflate-zlib x 60.60 ops/sec ±2.04% (67 runs sampled)


    Обратите внимание, что когда делаются прослойки к системным библиотекам, то маршалинг (проброс объектов в яваскрипт и обратно) не бесплатный. Поэтому на «лёгком» inflate получился забавный результат, когда «яваскриптовый код быстрее сишного». Конечно это не так. На тестах deflate, где действительно высокая нагрузка на процессор, доля расходов на маршалинг невелика, и отношение скоростей выглядит правдоподобным.

    Это НЕ asm.js. Обычный яваскрипт. Бенчмарки, к сожалению, только под v8. Но отношение скоростей между другими браузерами можно посмотреть в трекере известной библиотеки jszip, авторы которой сейчас тестируют pako.

    Комментарии 12

      +1
      Что им мешало на asm.js написать, кстати?
      Он же вроде и в браузерах без его поддержки вполне себе работает.
        +4
        asm.js это все же костыль. И если на v8 удается получить такую же производительность и без него — то почему бы и нет?
          +1
          Костыль, да, но с ним было бы так же быстро (или быстрее) и в FF :-)
            –1
            Не совсем. asm.js потому и не реализован в v8, что ему в множестве случаев удается оптимизировать обычный JS до такой же производительности, что и asm.js+ФФ. Во всяком случае, представленный код не отличается особой мудреностью.
              +1
              Не-не. Вы, наверно, читая мой коммент, прочли слово «как» там, где его нет :-)
              Ок, в v8 быстро, замечательно. Почему не сделать так, чтобы было быстро и в FF?
                +1
                Точно) Ну если уж на то пошло, то для компиляции в asm.js вообще не нужно ничего писать — скомпилировать исходную С-библиотеку в Emscripten и вуаля. Но это же скучно :)
                  0
                  Ну и судя по всему, ФФ авторов вообще не интересовал в рамках данного проекта:
                  Goal was having fun with investigation v8 jit speed
                    0
                    Ну тогда да, понятно.
                    +2
                    у вас же есть emscripten, скомпилируйте v8 под asm.js и у вас будет так же быстро
                      +1
                      Ну да, да, не подумал :-)
            +1
            Насколько я понял сравнивалась время выполнения теста осуществляющего вызовы js библиотеки со временем выполнения этого же теста делающего вызовы c-шной библиотеки через маршалинг. Мне кажется это не вполне корретно, так как маршалинг съедает какое-то время и возможно не мало. Для корретного тестирования стоило бы написать аналогичный тест на C и сравнивать его результаты с js тестом.
              0
              Так задача изначально стоит именно в использовании
              для браузера и node.js
              , поэтому сравнивать нужно C с вызовом из JS или реализацию полностью на JS. Вот если бы мы измеряли на каком языке быстрее будет работать сам алгоритм, то связку бы не учитывали, но тут то и ответ заранее ясен.

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

            Самое читаемое