The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Сравнение производительности различных реализаций WebAssembly"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Сравнение производительности различных реализаций WebAssembly"  +/
Сообщение от opennews (?), 06-Июл-18, 11:38 
Разработчики PSPDFKit представили (https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc.../) новый инструментарий (https://github.com/PSPDFKit-labs/pspdfkit-webassembly-benchmark) для измерения производительности реализации WebAssembly в различных web-браузерах, нацеленный на воспроизведение ситуаций, типичных для реальных проектов на C/C++, скомпилированных в WASM. Напомним, что WebAssembly предоставляет (https://www.opennet.dev/opennews/art.shtml?num=46117) не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования.

При тестировании выполняются различные процедуры обработки  PDF-файлов и замеряется как производительность выполнения операций, так и суммарное время с учётом загрузки и компиляции псевдокода WASM.
Лидером при тестировании производительности стал Firefox, который выполнил набор тестов WebAssembly в 2.4 раза быстрее, чем  Chrome, в 8.7 раз быстрее Edge и в 6.4 раза быстрее Sagari. В Chrome 69 ожидается рост производительности WebAssembly благодаря включению  нового  оптимизирующего компилятора для WebAssembly, который пока доступен только через экспериментальный флаг enable-webassembly-baseline. Тем не менее, включение данного флага в текущих экспериментальных выпусках Chrome приводит к увеличению производительности примерно на 20%, т.е. Firefox всё равно остаётся в два раза быстрее.


Примечательно, что в Edge и  Sagari из-за длительной фазы компиляции и отсутствия некоторых важных оптимизаций тест  WebAssembly выполнялся дольше, чем аналог на JavaScript. Производительность WebAssembly  и JavaScript в Chrome отличается незначательно. Наибольшая разница в скорости выполнения тестов WebAssembly  и JavaScript зафиксирована в Firefox.

URL: https://pspdfkit.com/blog/2018/a-real-world-webassembly-benc.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=48919

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Сравнение производительности различных реализаций WebAssembl..."  –1 +/
Сообщение от хрю (?), 06-Июл-18, 11:38 
>Примечательно, что в Edge и Sagari из-за длительной фазы компиляции и отсутствия некоторых важных оптимизаций тест WebAssembly выполнялся дольше, чем аналог на JavaScript.

Да в хроме тоже отличие не поражает на повал. WebAssembly пока оправдан только для ff, а как дышаль, а как дышаль.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Сравнение производительности различных реализаций WebAssembl..."  –1 +/
Сообщение от _Vitaly_ (ok), 06-Июл-18, 12:42 
На математике (image resize) у FF я как-то не заметил прорывов. WA везде примерно на 0-25% пошустрее оптимизированного js, но в FF постабильнее - там js иногда залипает, если тест много раз запускать.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Сравнение производительности различных реализаций WebAssembl..."  +8 +/
Сообщение от хрюгль (?), 06-Июл-18, 12:43 
а мы эту хрень придумали вовсе и не для производительности (это мазила, как обычно, повелась на рекламу и неверно поняла задачу).
Просто obfuscated js что-то стали быстро реверсить.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

14. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Урри (?), 06-Июл-18, 13:05 
> Просто obfuscated js что-то стали быстро реверсить.

Ну расскажи нам, очередной адепт "васм для хакеров, js слишком понятен", что делает вот этот чистый, НЕобфусцированный JS код из боевого проекта:
заодно можешь рассказать чем он более понятен аналогичного wasm кода.

    $152 = ($143 | 0) == ($141 | 0);
    if ($152) {
     $153 = 1 << $138;
     $154 = $153 ^ -1;
     $155 = HEAP32[(gb + 169192 | 0) >> 2] | 0;
     $156 = $155 & $154;
     HEAP32[(gb + 169192 | 0) >> 2] = $156;
     break;
    }
    $157 = ($143 | 0) == ($145 | 0);
    if ($157) {
     $$pre441 = $143 + 8 | 0;
     $$pre$phi442Z2D = $$pre441;
    } else {
     $158 = HEAP32[((gb + 169192 | 0) + 16 | 0) >> 2] | 0;
     $159 = $158 >>> 0 > $143 >>> 0;
     if ($159) {
      _abort(), asyncState ? abort(-12) | 0 : 0;
     }
     $160 = $143 + 8 | 0;
     $161 = HEAP32[$160 >> 2] | 0;
     $162 = ($161 | 0) == ($10 | 0);
     if ($162) {
      $$pre$phi442Z2D = $160;
     } else {
      _abort(), asyncState ? abort(-12) | 0 : 0;
     }
    }
    $163 = $141 + 12 | 0;
    HEAP32[$163 >> 2] = $143;
    HEAP32[$$pre$phi442Z2D >> 2] = $141;

p.s. Как же эти макаки задрали...

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от Илья (??), 06-Июл-18, 13:24 
Действительно, макакам не понять всей боли, которая ожидает того, кто будет читать ваш код. Как вы да такого вообще дошли и зачем?
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от Аноним (17), 06-Июл-18, 13:36 
Может он бывший фортранист?
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

20. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от sklsmgw (?), 06-Июл-18, 14:00 
Это результат работы Emscripten :-)
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от хрюгль (?), 06-Июл-18, 15:07 
то есть по сути того же Wasm, но от другой лавочки.

Ну и что вас удивляет? Мы не любим это ваше llvm, и сделали свое - с блэкджеком, небыстрое, потому что нужна была вовсе не скорость - и заставили всех заимплементить, поэтому оно будет работать у всех, хотят они того или нет. Хахахахахаха!

(уходит причинять всем добро)

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

47. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Урри (?), 06-Июл-18, 18:52 
Нет, это не wasm. Это старый добрый asm.js, который уже 5 лет как вовсю используется в вебе (https://en.wikipedia.org/wiki/Asm.js).

И, на минуточку, это именно что JS - он работает на всех без исключения js виртуальных машинах, просто на старых он будет работать медленно, а на новых - очень быстро.

Имея asm.js я бы сказал, что wasm не нужен, ибо толку с него, почти как с козла молока. Но wasm, теоретически, можно транслировать под любую виртуальную машину, в то время как asm.js жестко привязан к джаваскрипту.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

51. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от пох (?), 06-Июл-18, 19:02 
дык, не переживайте - теперь точно так же "на всех без исключения" (обоих) будет работать и честный webasm.

> Но wasm, теоретически, можно транслировать под любую виртуальную машину

но зачем?

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

68. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (68), 07-Июл-18, 15:25 
Не будет. Вы не понимаете - asm.js, это тот же JS, просто специально оформленный, что позволяет модным js машинкам его очень быстро исполнять. Но и старые js тоже его будут выполнять, просто "как обычно", без ускорения.

Wasm же требует специальное расширение в браузере. Старые браузеры его выполнять не смогут.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

70. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от Аноним (70), 07-Июл-18, 21:23 
Когда код, где все названия переменных представлены числами, называют необфусцированным...

Серьёзно???

Да ещё и кусок кода без изначального присвоения значений этим переменным - ну-ка быстро сказали что делает этот кусок кода!...


> p.s. Как же эти макаки задрали...

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

74. "Сравнение производительности различных реализаций WebAssembl..."  –1 +/
Сообщение от Аноним (68), 09-Июл-18, 17:07 
Еще раз - это нормальный, обычный, необфусцированный JS код, которого в вебе уже 5 лет как полным полно. И который выполняется в любых, даже очень старых (умеющих в js) браузерах, даже под телевизорами.

Ну и я, конечно, могу вам предъявить все N-тысяч строк, но смысл? Ведь и так понятно, что от замены вот этого выше на wasm хуже точно не станет.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

76. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (70), 11-Июл-18, 09:22 
Ознакомьтесь со значением слов, которыми пытаетесь оперировать:

Обфуска́ция (от лат. obfuscare — затенять, затемнять; и англ. obfuscate — делать неочевидным, запутанным, сбивать с толку) или запутывание кода — приведение исходного текста или исполняемого кода программы к виду, сохраняющему её функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

31. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 06-Июл-18, 15:32 
Если у тебя asm.js мегабайт на 30 - то аналог в WebAssembly будет меньше раза в два и шустрее запускаться раз в пять.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

34. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от нах (?), 06-Июл-18, 15:59 
а выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?

P.S. "зато мы победили npapi и прочие binary plugins". Которые решали эту задачу, хотя бы, эффективно (и заметно для пользователя, а вот это нехорошо)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

37. "Сравнение производительности различных реализаций WebAssembl..."  +6 +/
Сообщение от Аноним (37), 06-Июл-18, 16:04 
>выкинуть нахрен то и другое и перенести обработку на сервер, где с ней справится native бинарник на 30 килобайт - уже совсем нельзя?

Перенести майнинг на сервер? Смишная шутка

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

40. "Сравнение производительности различных реализаций WebAssembl..."  +4 +/
Сообщение от sklsmgw (?), 06-Июл-18, 16:51 
довольно сложно перенести, например, отрисовку сцены игры на сервер
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

52. "Сравнение производительности различных реализаций WebAssembl..."  –2 +/
Сообщение от пох (?), 06-Июл-18, 19:04 
> довольно сложно перенести, например, отрисовку сцены игры на сервер

авторы doom (и по-моему wolf3d с ними) смотрят на вас с некоторым удивлением.

наоборот же ж ровно - на сервере у тебя есть видеокарта (и не одна, если это такой специальный отрисовочный сервер), а проблемы 60fps over ip давным-давно решены.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

55. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от Аноним (55), 06-Июл-18, 20:21 
>проблемы 60fps over ip давным-давно решены

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

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

56. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от пох (?), 06-Июл-18, 20:50 
а у вас что - игры еще и однопользовательские (авторы doom...ну вы поняли ;-) ?
в остальных случаях - все равно ж надо их как-то решать.

И проблема будет в rtt, а не в полосе.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

69. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Xasd (ok), 07-Июл-18, 16:14 
> а у вас что - игры еще и однопользовательские (авторы doom...ну вы поняли ;-) ?

Doom вообще-то однопользовательский. не считая прикрученный проволокой мультиплеер, в котором на 30 минут пострелять.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

41. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от Crazy Alex (ok), 06-Июл-18, 17:11 
Можно теоретически. Но:
1) если это игра или даже интерактивный редактор процесс обмена с сервером может оказаться куда более тормозным, чем переживёт пользователь.
2) масштабирование хреновое. А так всё просто - пользователь запустил, у него всё и крутится. И, в общем, ведёт себя прилично даже на мобиле.
3) это надо делать клиент-сервер вместо того, чтобы перетащить готовый десктопный софт сравнительно умеренными усилиями.

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

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

44. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Ydro (?), 06-Июл-18, 17:55 
И давно у вас браузерные 3D игры строят логику рендереринга на сервере?
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

53. "Сравнение производительности различных реализаций WebAssembl..."  –2 +/
Сообщение от пох (?), 06-Июл-18, 19:05 
> И давно у вас браузерные 3D игры строят логику рендереринга на сервере?

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


Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

63. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 07-Июл-18, 11:59 
Почему без доступа? OpenGL ES там сто лет как
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

48. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Урри (?), 06-Июл-18, 18:56 
> будет меньше раза в два и шустрее запускаться раз в пять.

К сожалению, не будет.
https://hacks.mozilla.org/files/2016/10/asmjs-wasm-compariso...

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

64. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 07-Июл-18, 12:02 
Так у них там ничего крупного и нет. С определённого размера asm.js тупит. Я для живого продакшна это дело гонял, пришлось померить. Там много причин - например, asm.js надо догрузить целиком прежде, чем он начнёт парситься, а для wasm это делается по ходу загрузки, и это никак не лечится.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

3. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Попугай Кеша (?), 06-Июл-18, 11:45 
Посидим, подождем. Рядовым разрабам WASM не нужен. Он скорее нужен для тех, кто компиляторы пишут из божественного Rust, Go, C++ в WASM.

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

Это как DX/OpenGL/Vulkan никто напрямую не использует, а юзают просто игровые движки и все счастливы.

Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.

У C# неплохие перспективы тут, у QT.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Урри (?), 06-Июл-18, 12:49 
> Пожелаем удачи WebAssembly. Просто хорошая площадка для портирования приложух не JS в окружение, где раньше был JS.

Одна проблема - нечем портировать. Emscripten каждый месяц ломают обратную совместимость и не пишут документацию. Уже заeбался все время под новые сдк переделывать, плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.

Из самой мякотки - выкинули возможность собрать в один модуль, теперь разных файлов сразу пять штук. Зачем?? Еще обломали динамически подгружаемые модули (точнее выкатили уже седьмую реализацию, совсем сломанную; на четвертой я сдался переделывать и слил все в статику - файл теперь, конечно, приходится сразу весь грузить). Но зато время на посратьcя с разработчиками альтернативных компиляторов (например https://github.com/leaningtech/cheerp-meta/issues/76) у них, конечно, есть.

В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим. Пришла новая идея? Нахер все ломаем и переделываем с нуля. С такими разработчиками у WebAssembly будущего нет.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

24. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от Андрей (??), 06-Июл-18, 14:53 
> плюнул - форкнул один из предыдущих полугодичной давности, зафризил и решил на новые совсем забить.

Форкнул - это когда продолжаешь развитие. Если зафризил - то можно было и просто сделать checkout того последнего ещё работающего для тебя релиза или даже коммита.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

29. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Андрей (??), 06-Июл-18, 15:15 
> В общем это выглядит как типичная студенческая RnD - никакого планирования, просто кодим.

По приведенной ссылки я вижу, что тот код (по крайней мере cheerp), что доступен всем на гитхабе - просто демка. Оптимизирующие патчи и поддержка POSIX, чтобы можно было не только бенчи компилировать, лежат в закрытых приватных репах и
> We actually provide extended support for POSIX APIs to our commercial customers with an add-on library.

Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет, что лучше emscripten, а по сути или хуже или практически на том же уровне.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

49. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Урри (?), 06-Июл-18, 18:57 
> Так что уж лучше открытый RnD, чем полуоткрытое непонятно что, которое пишет,
> что лучше emscripten, а по сути или хуже или практически на том же уровне.

Ну с этим я спорить не буду. Лучше.
Только в данном случае получается "редька вкуснее хрена", а толку?

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

42. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 06-Июл-18, 17:14 
Да и хрен бы с ним, asm.js у них точно так же менялся всё время, мешало это вполне умеренно. Тупо пишешь в скриптах развёртывания или в доках конкретную версию и в emsdk-portable её и устанавливаешь.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

59. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от mumu (ok), 07-Июл-18, 01:34 
Я конечно с другой планеты, но вот эти конкретные "зафриженые" версии разве потом не имеют проблем с безопасностью?
Помню когда все клали JQuery на сайтики и он абсолютно всегда был старый и дырявый.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

65. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 07-Июл-18, 12:08 
Не больше, чам старые "зафриженые" версии gcc. Вообще безопасностью там в основном занимается песочница браузера. Что-то может быть (допустим, если сделать как-то особо тупо загрузку asm.js), но шансов мало по многим причинам.
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

4. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Аноним (4), 06-Июл-18, 11:52 
Firefox стабильно удерживает лидерство по производительности. Хрому пора переходить на spidermonkey.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (7), 06-Июл-18, 12:07 
Судя по графику, spidermonkey уступает V8 на 30% (JavaScript). Это Фурифоксу пора переходить на V8. WASM же быстрее на FF.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Сравнение производительности различных реализаций WebAssembl..."  –2 +/
Сообщение от Аноним (9), 06-Июл-18, 12:29 
Как пользователь Firefox уже в течении лет 10ти могу подтвердить тот факт что ЖАБАскрипт в нем тормознее чем Chrome, даже Edge.

Раздражает еще тот факт что по памяти firefox течет не реально жутко, для примера, браузинг с 5-6 вкладками занимает 500-800 мб, но через минут 10 firefox уже весит около 1.9-2гб озу при тех же 5-6 вкладках но другими сайтами. Наводит на тот факт что память за собой ой как лениво он подчищает. Если зайти в about:memory и нажать "Minimize memory usage" внезапно очищается 1.2-1.5 гб мусора.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

28. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Аноним (28), 06-Июл-18, 15:11 
Я тебе секрет открою, никому не говори: эти 1.2-1.5Гб "мусора" на 100% состоят из кэшированных картинок и прочей медиаинформации, чтобы у тебя при браузинге ничего не тормозило и жесткий диск с сетью не насиловались лишний раз.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

38. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от Иван (??), 06-Июл-18, 16:21 
Я, как пользователь ФФ со стажем более 10 лет, что нужно бы Вам проверить настройки и расширения - это ненормальное явление для ФФ.
У меня более-менее постоянно висит 30-40 вкладок + 27 расширений - редка за 1 гигабайт ФФ выходит. Конкретно сейчас, 41 вкладка - 764 МБ.

P.S. Ах, да, я до сих пор на  ESR 52-й версии - из-за старых расширений, которым не могу найти замену, а самому писать лень. Но новые версии, вроде как, даже пошустрее и меньше памяти занимают, но врать не буду :)

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

67. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Почти Аноним (?), 07-Июл-18, 13:39 
Пиши список расширений. Найду отличную замену всем 100%.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

71. "Сравнение производительности различных реализаций WebAssembl..."  –1 +/
Сообщение от Аноним (71), 07-Июл-18, 23:13 
Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак и хромоподобные это умеют из коробки, старая опера тоже умела, а вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

72. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Почти Аноним (?), 08-Июл-18, 04:54 
> Как насчёт чего-нибудь для открывания mht и сохранения в нём же? Ишак
> и хромоподобные это умеют из коробки, старая опера тоже умела, а
> вот в файрфоксе оба имевшихся дополнения с переходом на quantum отвалилилсь.

А это чем плохо? Умеет сохранять страницу полностью в один файл.
https://addons.mozilla.org/ru/firefox/addon/save-page-we/

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

75. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (75), 09-Июл-18, 23:38 
Tab Kit 2nd Edition + дополнения к нему.
В свое время искал - отличных замен в упор не было видно. Поделки типа Tree Style Tab не предлагать: знаю, пользовался - до Tab Kit далеко.
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

77. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от OldFart (?), 24-Ноя-18, 11:07 
SQLite Manager ?
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

60. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от mumu (ok), 07-Июл-18, 01:37 
> Если зайти в about:memory и нажать "Minimize memory usage" внезапно очищается 1.2-1.5 гб мусора.

У меня так было из-за аддонов. И это был прямо косяк разработчика аддона.
В общем текучесть это не баг, а фича, т.е. какой-то гунокод на JS не делает нормально уборку памяти, заставляя (по логике программы) хранить все эти объекты, а виноват почему-то FF?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

61. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от mumu (ok), 07-Июл-18, 01:40 
p.s. Проблема довольно эффективно решается Tab Suspender-ами, которые тушат все фоновые вкладки.
Кстати, у меня так же сделано и в хроме, который в противном случае ел бы у меня порядка 12-14 Гигабайт за сессию. Но не из-за текучести,а  из-за выделения по 150 Мб на каждую вкладку.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

45. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (45), 06-Июл-18, 18:19 
Когда проводил различные тесты, JS фокса был в целом чуть быстрее хрома, который был чуть быстрее ноды, которая была в несколько раз быстрее эджа
Так что V8 vs Spider - вопрос спорный
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

16. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Аноним (16), 06-Июл-18, 13:29 
Почему-то тесты проводятся на таком железе как i7 / 32GB. Видимо скоро всем срочно придётся выкинуть на помойку свои девайсы с 4 и 8 ГБ памяти, чтоб не тормозило!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от 123 (??), 06-Июл-18, 14:00 
Потому что 16 ГБ уже недостаточно!
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

30. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (30), 06-Июл-18, 15:15 
ГБ недостаточно
Даешь ТБ в каждый планшет!
Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

33. "Сравнение производительности различных реализаций WebAssembl..."  –2 +/
Сообщение от Аноним (33), 06-Июл-18, 15:47 
8 уже минимум. Причем минимум такой.. не особо комфортный. Новую машину меньше чем с 16 я бы крайне не советовал покупать. Как некоторые живут на 4 и меньше не представляю. Машина будет однозадачной.

p.s. я не говорю, что мне это нравится или устраивает, просто это факт.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

36. "Сравнение производительности различных реализаций WebAssembl..."  –3 +/
Сообщение от Аноним (36), 06-Июл-18, 16:02 
Вполне комфортно с 4 ГБ одновременно играю в Minecraft (ему выделено 1.5 ГБ вместо стандартного 1 ГБ), сижу в Firefox и общаюсь в Discord. Памяти хватает.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

18. "Сравнение производительности различных реализаций WebAssembl..."  –1 +/
Сообщение от Аноним (33), 06-Июл-18, 13:45 
Я не очень понимаю как будет выглядеть исходник веб-страницы с этим вебассембли? Мне предлагают запускать левый исполняемый файл у себя в браузере и молиться, чтобы песочница браузера была не дырявая?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Сравнение производительности различных реализаций WebAssembl..."  +17 +/
Сообщение от Алексей (??), 06-Июл-18, 14:20 
Ты и сейчас загружаешь себе левый JS-файл и молишься, что бы песочница была не дырявая.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (22), 06-Июл-18, 14:23 
>молиться, чтобы песочница браузера была не дырявая?

именно так

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

27. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от хрюгль (?), 06-Июл-18, 15:10 
>>молиться, чтобы песочница браузера была не дырявая?
> именно так

и noscript тебе от него не поможет, потому что это не скрипт.
Для того и делали.

Ишь, взяли моду, копаться в нашем прекрасном коде!

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

46. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Аноним (45), 06-Июл-18, 18:22 
> и noscript тебе от него не поможет, потому что это не скрипт.

С noscript жить в современном мире вообще невозможно. Особенно если речь о современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

54. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от пох (?), 06-Июл-18, 19:11 
> современных одностраничных сайтах (что добавляет скорости загрузки страниц, кстати)

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

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

noscript, кстати, слегка помогает - если соединения для script src= не открываются ;-)

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

66. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Crazy Alex (ok), 07-Июл-18, 12:11 
Запросто можно, я так живу. Этих самых "современных одностраничных" довольно мало, да и там обычно достаточно разрешить полтора домена - это если вообще какое-то взаимодействие с ними нужно, а не открыл - посмотрел/прочёл/закрыл.
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

73. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от Аноним (-), 09-Июл-18, 16:24 
>С noscript жить в современном мире вообще невозможно. Особенно если речь о современных

Я вам скажу крамольную мысль, только пусть, пожалуйста, причастные не обижаются. А ненужны эти современные вебы. Не открылось? Вебмакака сама виновата. Рано или поздно ей прилетит от начальника.

Для юзера сплошная польза: лучше выйти прогуляться, чем на очередной информационный мусор пялиться.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

62. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от kaa (??), 07-Июл-18, 10:58 
> и noscript тебе от него не поможет, потому что это не скрипт.

wasm подгружается из js (да и сам по себе не имеет доступа к большей части api браузера)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

23. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от анонимтут (?), 06-Июл-18, 14:35 
На сайте mozilla есть примеры. Либо так <script type='module'>, либо fetch
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

25. "Сравнение производительности различных реализаций WebAssembl..."  +3 +/
Сообщение от Xasd (ok), 06-Июл-18, 14:58 
> левый исполняемый файл у себя в браузере

он не исполняемый

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

32. "Сравнение производительности различных реализаций WebAssembl..."  +2 +/
Сообщение от Crazy Alex (ok), 06-Июл-18, 15:37 
Ровно так же, как и сейчас с джаваскриптом. Даже не так - у JS есть доступ к DOM и прочим API браузера, у WASM  в текущей реализации его нет, используется джаваскриптовый бридж. Ни в чём у WASM нет больше полномочий, чем у джаваскрипта.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

35. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от demimurychemail (ok), 06-Июл-18, 16:00 
Тут что-то не так.
Буквально неделю назад я собирал сканер qr кодов, который в случае wasm показал количество отсканированных кодов в 11 раз больше чем та же реализация на джаваскрипт.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Сравнение производительности различных реализаций WebAssembl..."  +/
Сообщение от Урри (?), 06-Июл-18, 19:00 
> в 11 раз больше чем та же реализация на джаваскрипт.

Попробуй asm.js; плюсы - будет работать даже в старых телевизорнызх браузерах, минусы - чуть-чуть медленнее васма.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

57. "Сравнение производительности различных реализаций WebAssembl..."  +4 +/
Сообщение от Аноним (57), 06-Июл-18, 20:56 
обколются своими веб-приложениями и потом майнят биткойны во вкладках
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

58. "Сравнение производительности различных реализаций WebAssembl..."  +1 +/
Сообщение от Аноним (58), 06-Июл-18, 21:44 
Что-то не все так просто. У меня тоже тест запощен для декодирования WebP

https://demo.elibsystem.ru/node/35841

Разницу WebAssembly с JS в Firefox вообще не видно, а в JS заметно быстрее Firefox при первом запуске теста, что наводит на мысли, что Firefox оптимизирует JS заранее, а Chrome при выполнении.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру