Комментарии 46
Единственная проблема, которая сохраняется до сих пор – это перерасход памяти для используемой объектной модели и связанные с этим накладные расходы: нагрузка на процессор, память и, как следствие, аккумулятор. Собственно, для этого незачем писать мини-диссертацию.
Дело в том, что с появлением WASM ситуация изменится в пользу JS. Производители и так обратили свое внимание на проблему производительности и выработали решение, которое, вероятно привнесет совершенно другие скорости в вебстек. И тогда уже проблемы могут начаться у нативных приложений, например с меньшей гибкостью и накопленной за годы унификацией.
Дело в том, что с появлением WASM ситуация изменится в пользу JS. Производители и так обратили свое внимание на проблему производительности и выработали решение, которое, вероятно привнесет совершенно другие скорости в вебстек. И тогда уже проблемы могут начаться у нативных приложений, например с меньшей гибкостью и накопленной за годы унификацией.
Помоему, WebAssembly не слишком улучшит производительность веба, ведь, фактически, Jit-компиляторы точно так же работают по принципу AST и в ходе выполнения (а не первичной загрузки) должны давать такой же порядок производительности. Главная фича WebAssembly, по моему скромному мнению, — привнесение в клиентский веб новых языков и новых парадигм из этих языков. Но для того, чтобы новые парадигмы улучшили ситуацию с производительностью нужно накопление базы соответствующего кода.
WASM – это по сути браузерный байткод наподобие JVM. Т.е. код с полностью ручным управлением памятью и чистыми типами приводимыми к JS. В данном случае JS нужен только для связывания. Т.е. вы пишете на JS, а когда нужно спускаетесь на уровень ниже и пишете супер-оптимизированный код.
Там же не байткод вроде, а AST, но для меня самым важный вопрос, как происходит управление памятью в этом самом WASM? Если там принудительный сборщик мусора, то особого профита всё равно не будет.
А толку то? Проблема же в самом JS, а вот новые языки не факт, что хорошо в WASM влезут. Тут спасут только zero cost абстракции, а они сложнее для восприятия. Короче говоря, пока эти абстракции не станут по настоящему простыми и понятными, но не будут при этом существовать в результирующем коде, веб будет тормозить.
WASM – это и есть та самая zero cost абстракция. Это низкоуровневый код исполняемый в браузере. Да, некоторые ограничения будут, но скорость приблизится к C в значительной степени.
И все же коэффициент 5 приемлем для x86, прежде всего потому, что x86 в 10 раз быстрее, чем ARM.Еще с момента выхода оригинала меня интересовал вопрос: а как же модные серверы на ARM? Это, конечно, специфичная ниша, но пользуются же люди.
Цена серверов на ARM соответствует этим коэффициентам. Выигрыш от ARM-серверов в другом. Задача обработки запросов в вебе очень хорошо выполняется в многопоточной среде, практически линейная зависимость скорости обработки от числа физических потоков исполнения, минимум затрат на диспетчиризацию и смену контекста. В большинстве случаев получится, что большое число медленных потоков на ARM экономически выгоднее нескольких быстрых потоков на Xeon. А клиенту разница между 2мс и 20мс в современном вебе не заметна. Тем более, что сверху наложится пропускная способность канала, пинг, загрузка зависимостей…
Просто эта статья из далёкого прошлого, к тому же приправленая нескрытым PR от Интел.
Автор сравнивает ужа с ежом — с каким же x86 процессором сравнивается древний Cortex-A9 (образца 2007г) не ясно.
>> версия 22 нм x86 Atom Bay Trail от Intel в настоящее время не существует. Intel пришлось изобретать совершенно новую разновидность проводника, так как стандартная разновидность не работала в масштабе 22 нм. Думаете, они продадут ARM лицензию на нее?
Новую простите что?
1) FinFet является не какой-то эксклюзивной технологией Интел, а технологией которую используют все фабрики.
2) ARM-у на это вообще плевать. Они не выпускают процессоры, а лицензируют архитектуру и hard/soft IP.
>>Подумайте еще раз. В мире всерьез планируется построить лишь несколько предприятий по производству интегральных схем 22 нм, и большинство из них контролирует Intel.
Современные ARM создаются на 14нм техпроцессе и соперничают с процессорами того же класса (Core-m) от Intel
http://www.anandtech.com/show/9766/the-apple-ipad-pro-review/4
Автор сравнивает ужа с ежом — с каким же x86 процессором сравнивается древний Cortex-A9 (образца 2007г) не ясно.
>> версия 22 нм x86 Atom Bay Trail от Intel в настоящее время не существует. Intel пришлось изобретать совершенно новую разновидность проводника, так как стандартная разновидность не работала в масштабе 22 нм. Думаете, они продадут ARM лицензию на нее?
Новую простите что?
1) FinFet является не какой-то эксклюзивной технологией Интел, а технологией которую используют все фабрики.
2) ARM-у на это вообще плевать. Они не выпускают процессоры, а лицензируют архитектуру и hard/soft IP.
>>Подумайте еще раз. В мире всерьез планируется построить лишь несколько предприятий по производству интегральных схем 22 нм, и большинство из них контролирует Intel.
Современные ARM создаются на 14нм техпроцессе и соперничают с процессорами того же класса (Core-m) от Intel
http://www.anandtech.com/show/9766/the-apple-ipad-pro-review/4
Если верить исходной статье, то основная проблема в сборщике мусора, а от него в веб приложениях никак не избавится от слова совсем.
Сборщик мусора есть в .net и java. Вроде бы никто не говорит о том что скорость этих платформ отличается в 5 раз от скорости C.
Есть одно больше НО, сборщик работает без лагов когда оперативки много, раз в 10 больше, чем реально требуется для задачи. А иначе ему приходится работать чаще. А на мобилках с памятью ещё хуже, чем с процессором.
А почему хуже? Насколько я понимаю энергопотребление с ростом объема памяти не растет настолько же линейно, насколько оно растет с ростом скорости процессора.
Современные смартфоны уже сравнялись с бюджетными десктопами по объему памяти — 1-2 гигабайта норма даже для дешевых, в этом году появятся смартфоны с 6 гигами памяти — на большинстве офисных компьютеров и недорогих ноутбуков вы таких объемов не увидите.
Современные смартфоны уже сравнялись с бюджетными десктопами по объему памяти — 1-2 гигабайта норма даже для дешевых, в этом году появятся смартфоны с 6 гигами памяти — на большинстве офисных компьютеров и недорогих ноутбуков вы таких объемов не увидите.
Вроде бы никто не говорит о том что скорость этих платформ отличается в 5 раз от скорости C.Все просто делают вид, что это не так. Запустите какой-нибудь CLion на десктопе с 2-4GiB памяти и сравните его с Visual Studio 6.0 на том же железе.
Засуньте 16-32-64GiB — результат будет совсем другим. На мобилках этой проблемы нет, так как все «тяжёлые» приложения не используют на .net, ни java. Вещи, которые реально требуют много ресурсов почти во всех популярных приложениях работают в нативных библиотеках. На этом, собственно, Windows Phone погорел (там было много дурости сделано, но тот факт, что WP7 поддерживал только C# был верхом идиотизма).
Вы забываете про энергопотребление. В статье сравнивают процессоры ARM и Intel потребление энергии которых отличается примерно на столько же, на сколько и производительность.
Если сравнивать производительность на ватт, то получается примерный паритет.
Но тут включается дополнительный фактор — цена Intel практически монополист на рынке x86 и устанавливает высокие цены.
ARM может делать кто угодно и ценовая конкуренция там жесточайшая. Это очень наглядно видно по стоимости ноутбуков и планшетов (если не считать Atom которые Intel делает себе в убыток).
Если сравнивать производительность на ватт, то получается примерный паритет.
Но тут включается дополнительный фактор — цена Intel практически монополист на рынке x86 и устанавливает высокие цены.
ARM может делать кто угодно и ценовая конкуренция там жесточайшая. Это очень наглядно видно по стоимости ноутбуков и планшетов (если не считать Atom которые Intel делает себе в убыток).
Если говорить о фактах, то лучший способ проверить скорость мобильных приложений — это написать такое приложение, а не мерять тесты производительности.
Мне было очень интересно посмотреть, можно ли быстро портировать веб приложение безо всяких усилий, и я это сделал.
В качестве исходника был один из моих пет проджектов. Он реализует большой и сложный лист для генерации персонажа для ролевой игры. Выглядит вот так (на скрине виден только один лист из четырёх плюс дополнительный интерфейс).
Я специально не стал использовать Cordova, Phonegap и подобное. Просто приложение с обычным WebView. Из дополнительного функционала добавил только авторизацию напрямую при помощи аккаунта google в телефоне.
Получилось вот такое простое приложение — github, google play.
Тестировал на двух устройствах, которыми пользуюсь — LG Nexus 5 и Sony Xperia Z3 Tablet Compact. Результаты превзошли все мои ожидания — приложение с довольно кривым, не модифицированным, тяжёлым и не компактизированным яваскриптом и стилями просто летает! При этом там используется JQuery, яваскрипт для bootstrap, несколько сторонних тяжёлых библиотек...
Для меня вывод довольно однозначен — да, конечно веб приложения медленнее работают на мобильной платформе, чем на десктопе. Это вполне очевидно и можно не доказывать. Но если вы рассчитываете на пользователей с современными устройствами и ваше приложение нормально работает на десктопе — у вас не возникнет ровным счётом никаких проблем. А выгода от написания единой адаптивной версии интерфейса огромна.
P.S. Это всё справедливо для Android, но может быть неверно для iOS — не проверял.
Мне было очень интересно посмотреть, можно ли быстро портировать веб приложение безо всяких усилий, и я это сделал.
В качестве исходника был один из моих пет проджектов. Он реализует большой и сложный лист для генерации персонажа для ролевой игры. Выглядит вот так (на скрине виден только один лист из четырёх плюс дополнительный интерфейс).
Я специально не стал использовать Cordova, Phonegap и подобное. Просто приложение с обычным WebView. Из дополнительного функционала добавил только авторизацию напрямую при помощи аккаунта google в телефоне.
Получилось вот такое простое приложение — github, google play.
Тестировал на двух устройствах, которыми пользуюсь — LG Nexus 5 и Sony Xperia Z3 Tablet Compact. Результаты превзошли все мои ожидания — приложение с довольно кривым, не модифицированным, тяжёлым и не компактизированным яваскриптом и стилями просто летает! При этом там используется JQuery, яваскрипт для bootstrap, несколько сторонних тяжёлых библиотек...
Для меня вывод довольно однозначен — да, конечно веб приложения медленнее работают на мобильной платформе, чем на десктопе. Это вполне очевидно и можно не доказывать. Но если вы рассчитываете на пользователей с современными устройствами и ваше приложение нормально работает на десктопе — у вас не возникнет ровным счётом никаких проблем. А выгода от написания единой адаптивной версии интерфейса огромна.
P.S. Это всё справедливо для Android, но может быть неверно для iOS — не проверял.
иос тоже неплохо работает, я скажу больше, даже кордова/фонгап работали бы быстро. Дело не в жквери или кол-ва жс кода, дело в функциональности. Зайдите с телефона на гугл докс.
Летает на девственно чистом смартфоне? А если таких приложений там будет штук 10 в фоне висеть?
«640 КБ хватит всем» — «В лабораторной свежеустановленной системе наше приложение летает.»
«640 КБ хватит всем» — «В лабораторной свежеустановленной системе наше приложение летает.»
Нет, увы, девственность у моих устройств потеряна очень давно.
В фоне висит весь гугл зоопарк с документами, социальные сети, ещё несколько десятков веб страничек, скайп, Adobe Reader с огромными PDF и ещё десятка три приложений… Можно было это уточнить, но по-моему само собой подразумевается, что когда говорится "Тестировал на двух устройствах, которыми пользуюсь" — имеется в виду не свежеустановленная система.
В фоне висит весь гугл зоопарк с документами, социальные сети, ещё несколько десятков веб страничек, скайп, Adobe Reader с огромными PDF и ещё десятка три приложений… Можно было это уточнить, но по-моему само собой подразумевается, что когда говорится "Тестировал на двух устройствах, которыми пользуюсь" — имеется в виду не свежеустановленная система.
Вы тут немного о разных вещах говорите. Если у вас приложение, которому нет аналогов, то да, с версией на JS можно работать: в конце-концов 20 лет назад нативный код был медленнее, чем сегодняшний JavaScript, а люди с этим как-то жили.
Если же аналоги есть — то выиграет приложение, не использующее web-технологии. Почти всегда. Просто потому что оно будет меньше жрать батарейку, быстрее реагировать на кнопочки и так далее.
Если же аналоги есть — то выиграет приложение, не использующее web-технологии. Почти всегда. Просто потому что оно будет меньше жрать батарейку, быстрее реагировать на кнопочки и так далее.
Да, я действительно говорю про другое.По-моему странно ожидать, что приложение на яваскрипте может быть быстрее или хотя бы работать с той же скоростью, что и нативное и писать на эту тему статьи и бенчмарки.
Писал я как раз про то, что различие в скорости не имеет никакого практического значения для пользователя. Это мы говорим про некое стандартное приложение, а не то, которое он использует 80% дня — в этом случае различия по батарейке правда могут быть критичны.
А вообще, эта война против "медленного яваскрипта" сильно напоминает холивары на тему того, что для оптимизации всё надо писать на assembler. Да, можно. Да, работать будет быстрее. Нет, увеличит в разы время разработки и будет зависимо от платформы...
Писал я как раз про то, что различие в скорости не имеет никакого практического значения для пользователя. Это мы говорим про некое стандартное приложение, а не то, которое он использует 80% дня — в этом случае различия по батарейке правда могут быть критичны.
А вообще, эта война против "медленного яваскрипта" сильно напоминает холивары на тему того, что для оптимизации всё надо писать на assembler. Да, можно. Да, работать будет быстрее. Нет, увеличит в разы время разработки и будет зависимо от платформы...
Я выбрал «не продолжать перевод», ибо статья уже была переведена и перевод есть на хабре: https://habrahabr.ru/post/188580/
Я не понял часть про 60 лет…
Как идея JIT для JS быть 60 летней давности, если JS только 20 лет существует…
Или там какая-то тонкая мысль, которую я не уловил?
Как идея JIT для JS быть 60 летней давности, если JS только 20 лет существует…
Или там какая-то тонкая мысль, которую я не уловил?
JIT придумали в computer science ещё в 60ых годах, тогда же и про сборщик мусора теория появилась. Сейчас в ЯП потихоньку проникают на практике теоретические изыскания 70-80ых годов до сих пор. Практика очень сильно отстает от теории.
В тексте речь не про JIT. В тексте речь про JIT для JS.
В JIT для JS за последние 10 лет реализовали идеи, которые были обкатаны в <a href="https://ru.wikipedia.org/wiki/P-Мысль, которую автор хотел до вас донести: JavaScript, который мы видели в браузере 10 лет назад работал примерно так же, как какой-нибудь Lisp в середине 50х (внутренние идие, как ни удивительно, у них очень похожи — несмотря на радикально другой синтаксис): тупой интерпретатор "без выкрутасов". Сейчас его движок использует уже почти все те же идеи, что и современный Lisp (и также Java, C# и прочие). Фактически развитие JavaScript'а за 10 лет пробежалось по всему тому пути, по которому другие языки шли 60 лет. Но теперь всё — идеи, которые были давно известны, опробованы, обкатаны… кончились. Следующий подобный шаг займёт 60 лет, а не 10...
Статья вводит в заблуждение ибо предлагают идею что интерпретаторы JavaScript недостаточно производительны, что в корне не верно. Как и 10 лет назад на десктопе, сегодня в мобильном устройстве основное время (задержка) возникает в отрисовывании.
Производительность обычно как раз меряют в числе операций в секунду, но при этом задержка — это время, за которое будет выполнена та или иная операция. Отсюда следует, что чем выше производительность тем меньше задержка. Но есть еще проблема: при замерах производительности обычно берут большие объемы данных, поэтому время на подготовку к вычислениям пренебрежительно мало.
В случае с js ситуация ещё хуже: ему нужно время на прогрев, у него есть паузы на сборку мусора. В результате он может показывать много попугаев, но тупить в отрисовке.
В сухом остатке получается, что любой управляемый код нельзя к отрисовке подпускать ближе, чем на пушечный выстрел.
В случае с js ситуация ещё хуже: ему нужно время на прогрев, у него есть паузы на сборку мусора. В результате он может показывать много попугаев, но тупить в отрисовке.
В сухом остатке получается, что любой управляемый код нельзя к отрисовке подпускать ближе, чем на пушечный выстрел.
Когда мы говорим о приложениях в web (браузерах) то почему то все забывают, что бОльшую часть времени приложение проводит не в своем коде а в самом браузере, работа с DOM например и главное, расходы связанные с организацией приложения именно в таком виде.
Даже если javascript станет выполняться в 10 раз быстрее нативного кода, итоговые приложения будут всеравно безбожно тормозить
Даже если javascript станет выполняться в 10 раз быстрее нативного кода, итоговые приложения будут всеравно безбожно тормозить
мы обнаружили, что на Хабре еще не пробегал перевод великолепнейшей статьи под названием: «Почему мобильные веб приложения такие медленные?»
Пробегал: https://habrahabr.ru/post/188580/
НЛО прилетело и опубликовало эту надпись здесь
Никто не предполагал *цать лет назад, что вам взбредёт в голову писать на javascript что-либо серьёзнее интерактивных страничек. Так что нефиг жаловаться, мол, оно медленное. Используйте инструменты по назначению.
Не совсем понятна цель статьи. Убедить писать нативные приложения? Но ведь быстродействие далеко не единственный фактор выбора. Если команда большая, или вы специалист именно по разработке нативных приложений, то почему нет?
В противном случае уже сейчас можно смотреть в сторону React native.
Статья довольно старая, и в ней не рассматриваются подобные альтернативы. Да и ARM уже на 14 нм.
В противном случае уже сейчас можно смотреть в сторону React native.
Статья довольно старая, и в ней не рассматриваются подобные альтернативы. Да и ARM уже на 14 нм.
Слово native (которое вы перевели как «собственный») лучше было оставить без перевода, вы исказили смысл, а достойного аналога фразе «native-приложение» в русском нет. Даже калька «нативное приложение» лучше смысл передает.
Основываясь на докладе с JSConf EU в этом году (вот этот доклад, если не ошибаюсь), при правильном написании, JS отстаёт по производительности от C на ~16%.
Но как уже кто-то заметил выше, в веб приложениях не так сильно важна скорость, а писать программы, от которых требуется высокая производительность, можно и на другом языке, раз уж на то пошло.
Вопрос к автору: почему движки в сравнении 12-13 годов? Как-то странно смотреть на сравнение Chrome 26, когда у тебя стоит Chrome 48...
Но как уже кто-то заметил выше, в веб приложениях не так сильно важна скорость, а писать программы, от которых требуется высокая производительность, можно и на другом языке, раз уж на то пошло.
Вопрос к автору: почему движки в сравнении 12-13 годов? Как-то странно смотреть на сравнение Chrome 26, когда у тебя стоит Chrome 48...
Вопрос к автору: почему движки в сравнении 12-13 годов?Ммм… А какие, собственно, движки вы хотели бы увидеть в статье вышедшей в середине 2013 года?
Как-то странно смотреть на сравнение Chrome 26, когда у тебя стоит Chrome 48...Дык. Но тот факт, что эту статью многие тут обсуждают не осознавая, что обсуждают нечто, чему скоро будет уже три года показывает насколько всё-таки прав автор — не так ли?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему мобильные веб-приложения такие медленные?