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

"Сравнение производительности различных реализаций 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..."	+/–
Сообщение от demimurych (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 | Индекс форумов | Темы | Пред. тема | След. тема