Дрю Кроуфорд (Drew Crawford), специализирующийся на разработке мобильных приложений, опубликовал (http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/) подробный анализ проблем с производительностью мобильных web-приложений, мешающих им конкурировать с нативными программами. В статье сделаны неутешительные выводы: в силу особенностей динамического языка и методов работы с памятью, JavaScript-приложения существенно отстают по производительности от нативных программ и в ближайшем будущем навряд-ли ситуация заметно изменится, пр крайней мере без внесения изменений в язык и API. Наиболее перспективным в этом плане выглядит Asm.js (http://www.opennet.me/opennews/art.shtml?num=36468), низкоуровневое подмножество языка JavaScript со строгой типизацией.В текущем виде JavaScript слишком медленный для разработки мобильных приложений. Отставание по производительности от C/C++ оценивается примерно в 50 раз, а от Java/Ruby/Python/C# в 10 раз, если размер программы укладывается в 35 Мб, при дальнейшем увеличении размера приложения производительность деградирует экспоненциально. Наиболее жизнеспособным вариантом для продвижения JavaScript для разработки мобильных приложений называется доведение производительности мобильных устройств до уровня настольных систем. Сам язык, без кардинальных изменений, не позволяет приблизиться к производительности нативных программ. Проблемы также наблюдаются в реализации системы сборки мусора, которая не рассчитана на работу в окружениях с ограниченным ресурсом памяти.
URL: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
Новость: http://www.opennet.me/opennews/art.shtml?num=37421
> Наиболее перспективно в этом плане выглядит Asm.js, низкоуровневое
> подмножество языка JavaScript со строгой типизациейАга, сначала создадим себе проблемы на ровном месте, а потом будем героически с ними бороться, вбивая эпические костыли. Вебдванольненько.
Это какие проблемы создал JS относительно смартфонов? Месье не в курсе, что когда его проектировали, еще и смартфонов-то не существовало? Скорее уж проблемы в пользователях смартфонов, упорно пользующихся сайтами на JS на своих костыльных машинках.
> Это какие проблемы создал JS относительно смартфонов?Динамическая типизация, GC. Сразу понятно было что это быстрым не будет.
Анон, читай что пишешь. Это в середине 90-х было сразу понятно, что на гламурных смартфонах в 2010-х он будет тормозить, что ли?
В середине 90-х были ходовыми конфигурации Pentium ~166MMX, 32-64Mb. Современные смартфоны намного производительнее тех машин. (На моем ZOPO C2 3DMark выдает ~10fps)
> Сразу понятно было что это быстрым не будет.офигеть ты эксперт.
> Это какие проблемы создал JS относительно смартфонов?~ большая куча тупых веб гогнкодеров будет теперь херачить медленные, прожорливые и ненужные приложения для смартов. Вместе с такими же бездарными и тупыми CIOшниками совсем скоро будет очень трудно найти вменяемый смарт. Ну чтобы для приложения типа браузера и почты не нужно было носить в кармане портативную буржуйку с чемоданом дров.
вообще в этот шаблон:~ большая куча тупых %LANG_NAME% гогнкодеров будет теперь херачить медленные, прожорливые и ненужные приложения,
можно влепить оочень много чего
особенно сюда напрашивается самизнаетечто...
Что только не придумают лишь бы пяток самых нормальных скриптовых языков в браузер не впилить.
> Что только не придумают лишь бы пяток самых нормальных скриптовых языков в
> браузер не впилить.ящитаю, gw-basic'а было бы достаточно!
> Отставание по производительности от C/C++ оценивается примерно в 50 раз, а от
> Java/Ruby/Python/C# в 10 разСомнительные какие-то цифры. Я бы мог поверить что яваскрипт сопоставим с питоном (то есть в полтора/два раза), но чтобы в 10 раз?
Вообще ж писали, что Node.js очень быстрые по сравнению со всякими Питонами и Рубями.
На мобильных же устройствах! Думаю, что из динамики lua (или luaJit) показал бы наилучшие результаты.
Быстрые на x86/x86_64. А тут мало памяти и ARM.
Через год 2 гига мало будет.
> Через год 2 гига мало будет.вы, походу, гость из прошлого
Странно, что в один ряд воставили Java и Python. Между ними как бе осне больштй разрыв в производительности.
> бе осне больштй разрыв в производительности.Что не мешает и тому и другому быть редкостным тормозиловом :).
ахтунг анонимные аналитики в треде, все на космический корабль и летим в другую галактику.
он все понял
>JavaScript-приложения существенно отстают по производительности от нативных программВот это новость! А мужики-то не знают.
Не вполне понял.
В статье графики о том что javascript отстает по производительности. Ок принимаем это за аксиому, но тут же напрашивается вопрос, где сравнение не в попугаях, а на реальных задачах?То что javascript медленнее совсем не говорит о том, что его производительности недостаточно для эффективного решения таких то и таких то задач.
35 мегабайт джаваскрипта. Это что, angular.js?
> 35 мегабайт джаваскрипта. Это что,...
/*
* This file is part of the superpuper project.
*
* Copyright (C) 2011 The Vasya Pupkin. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
*/
/*
* In mathematics, the Pythagorean theorem — or Pythagoras' theorem — is a relation in
* Euclidean geometry among the three sides of a right triangle (right-angled triangle).
* In terms of areas, it states:
*
* In any right-angled triangle, the area of the square whose side is the hypotenuse
* (the side opposite the right angle) is equal to the sum of the areas of the squares
* whose sides are the two legs (the two sides that meet at a right angle).
*
* The theorem can be written as an equation relating the lengths of the sides a, b and c,
* often called the Pythagorean equation: where c represents the length of the hypotenuse,
* and a and b represent the lengths of the other two sides.
*
* The Pythagorean theorem is named after the Greek mathematician Pythagoras (ca. 570 BC—ca. 495 BC),
* who by tradition is credited with its discovery and proof,[2][3] although it is often argued
* that knowledge of the theorem predates him. There is evidence that Babylonian mathematicians
* understood the formula, although there is little surviving evidence that they used it in a
* mathematical framework.
* The theorem has numerous proofs, possibly the most of any mathematical theorem. These are very diverse,
* including both geometric proofs and algebraic proofs, with some dating back thousands of years. The
* theorem can be generalized in various ways, including higher-dimensional spaces, to spaces that are
* not Euclidean, to objects that are not right triangles, and indeed, to objects that are not triangles
* at all, but n-dimensional solids. The Pythagorean theorem has attracted interest outside mathematics
* as a symbol of mathematical abstruseness, mystique, or intellectual power; popular references
* in literature, plays, musicals, songs, stamps and cartoons abound.
*/
function pyth() {
c = Math.sqrt(a*a + b*b);
}
Уже жду аппаратную реализацию javascript и грелок (телефонов) с ядерным реакторам вместо батареи.
поэтому ведщроид всегда будет лагать, и жрать батарею. и всякие хромооси с фаерфокссистемами.
А Ведроид-то тут причём, Жабоскрипт с Жабой путаем? К тому же на Ведроиде можно нативненькое писать.
>C/C++ оценивается примерно в 50 раз, а от Java/Ruby/Python/C# в 10 разМежду нативом и явой разница в 5 раз.
>>C/C++ оценивается примерно в 50 раз, а от Java/Ruby/Python/C# в 10 раз
> Между нативом и явой разница в 5 раз.Докажи!
У меня от вас JIT, месье.
> У меня от вас JIT, месье.С JIT оно и сливает раза в три. Бенчи можно посмотреть допустим на quicklz.com - одна и та же библа в разных реализациях, один и тот же алгоритм. Ява и дотнет стабильно проиграли севой версии в 3 раза.
> поэтому ведщроид всегда будет лагать, и жрать батарею.Очень толсто (как программист на Obj-C/Java говорю)
> и всякие хромооси
Еще толще
>с фаерфокссистемами.
А тут в тему статьи ты наконец попал. Так ты троллил или только пытался? Незачёт
> Очень толсто (как программист на Obj-C/Java говорю)Спасибо, я видел как работает ведроид если там парочку программ запустить. Самый прикол - даже самый занюханный хелловорлд на этом менее 30Мб RSS не жрет в принципе. А т.к. там еще системой занято дофига - понятно что получается.
лол, капитан очевидносте!
уже даже плюсы довели до юзабельного состояния, а он о жабоскрипте думает
скомпилированная программа оказала быстрее интерпретируемой! ну надо же какое открытие! вот такие открытия делают "специалисты".
Поэтому Дрю Кроуфорд, специалист по разработке мобильных приложений. А не высер на опеннете.
> опеннете.Выceры на опеннете - прерогатива павлина :).
Интересный кусок:A Rust contributor weighs in:
I’m a contributor to the Rust project, whose goal is zero-overhead memory safety. We support GC’d objects via “@-boxes” (the type declaration is “@T” for any type T), and one thing we have been struggling with recently is that GC touches everything in a
language. If you want to support GC but not require it, you need to very carefully design your language to support zero-overhead non-GC’d pointers. It’s a very non-trivial problem, and I don’t think it can be solved by forking JS.
Правильнее назвать статью: "проблемы работы движков JS в браузерах для мобильных платформ" ... ИМХО - так все-же правильно.
И работы в этом направлении идут очень интенсивно ... причем как в плане самого движка JS так и того, каким CPU в мою устройствах ...
Чота я сомневаюсь что JavaScript медленее чем питон/руби, надо смотреть конечно что за тесты он там гонял. Но так-то JavaScript может действительно не хватает некоторых быстрых контейнеров (не аналога std::map, например) и алгоритмов
Да цифры что-то сомнительные
Например здесь JS по производительности выглядит очень неплохо. Понятно что тесты синтетические, но все-таки
http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
>В текущем виде JavaScript слишком медленный для разработки мобильных приложений. Отставание по производительности от C/C++ оценивается примерно в 50 раз, а от Java/Ruby/Python/C# в 10 раз, если размер программы укладывается в 35 Мб, при дальнейшем увеличении размера приложения производительность деградирует экспоненциально.В статье написано, что отставание в 5 раз, ещё 10 раз дают разница в железе десктопа и мобильных девайсов. Сравнения с Pythonом, Java и Ruby как такового не было, они просто вспоминались в процессе статьи. Текущую новость лучше удалить - слишком уж не соответствует оригиналу.
То, что по-видимому было искажено в результате перевода:>If you are an x86 C/C++ developer, think about the iPhone 4S web development as a C environment that runs at 1/50th the speed of its desktop counterpart. Per the benchmarks, you incur a 10x performance penalty for being ARM, and another 5x performance penalty for being JavaScript. Now weigh the pros and cons of working in a non-JavaScript environment that is merely 10x slower than the desktop.
50 раз здесь - нативные приложения на десктопе и JS на мобилке
>If you are a Java, Ruby, Python, C# developer, think about iPhone 4S web development in the following way. It’s a computer that runs 10x slower than you expect (since ARM) and performance degrades exponentially if your memory usage goes above 35MB at any point, because that is how garbage collectors behave on the platform. Also, you get killed if at any point you allocate 213MB. And nobody will give you any information about this at runtime “by design”. Oh, and people keep asking you to write high-memory photo-processing and video applications in this environment.
10 раз - по сравнению мобилки с десктопом, а не Java, Ruby, Python, C# vs JS. Деградация производительности при росте потребления памяти - это скорее проблема iPhone, чем JS.
Приложения на андройде почти все поголовно на яве, отсюда уже можно сделать вывод. Уже процы на топовые смартфоны ставят по 1.5ггц, да и память до 2х гигов вставляют, от этого хромает энергосбережение, если я у себя на самом слабеньком одноядерном процессоре 768 мгц еле еле выжимаю 10 рабочих дней, то я не представляю сколько работают топовые четырех\восьми яд., с всякими супер амоледами с разрешением 1920 на 1080, это ужас просто, день, два? Каждый день зарядка? Что это за кара такая?....
Если брать какой-либо известный современный флагман, то просто в роли звонилки в 2г-сети он более 4 дней не протянет никак.
2ГГЦ на АРМ это, в лучшем случае, 200МГц на Интеле по bogomips. В реальности, все еще хуже, за счет дико умных предсказателей и кешей всё той же компании. В своё время, у меня на каком-то втором пне интернет-странички так же тормозили :)
Будем думать с возвращением intel хоть и через процессоры для win8 конкуренция заставит немного почесаться. А так если там 2-4Вт термопакет, то что можно ожидать от сравнения хотя-бы с 17Вт Intel-а в i-3-5-7...U при равной частоте не может быть одинаковой производительности.
> если размер программы укладывается в 35 Мб,
> при дальнейшем увеличении размера приложения производительность деградирует экспоненциально.это вот что это такое за фигню я только что прочитал?
Подучите английский и выбросите этот отвратительный промт, которым вы переводили статью.
>от Java/Ruby/Python/C# в 10 раз, если размер программы укладывается в 35 Мбэто же ложь, где вы это нашли?
Я вижу:
>As long as their applications will be running on systems equipped with more than three times as much RAM as required, then garbage collection is a reasonable choice.Впрочем, я не знаю что я ожидал.
> выбросите этот отвратительный промт, которым вы переводили статью.тогда «пиривотчеку» придётся отрезать себе голову. не то, чтобы кто-то потом заметил разницу в интеллекте, но эстетика-с… да и кушает он туда.
p.s. «пиривот» взялся вот отсюда: «If you find yourself with 6 times as much memory as you need, garbage collection is actually going to be pretty fast. So for example, if you are writing a text editor, you might realistically be able to do everything you want in only 35MB, which is 1/6th the amount of memory before my iPhone 4S crashes.» и так далее. вот они, заветные «триццатьпятьмигабайтов».
ну, это ж опеннет: тут «пиривотчеки» традиционно понимают только цифры и fuck, остальное домысливают в меру своего идиотизма. ради чего на опеннет и хожу: сравнение оригинала и «пиривота» или «выжимки» часто неимоверно доставляет. вплоть до того, что «пиривотчик» на опеннете может написать полностью противоположное тому, что говорится в оригинале.
Откровение капитана Очевидность.
Страницы в 10+ мегабайт кода без учета картинок и флэша нужно добавлять в списки блокировок рекламы
развёрнутая статья, которая поясняет тупообезьянам, отчего их жысы-поделки всегда будут сосать.и совершенно бесполезная, потому что тупообезьяны не то, что понять — они и прочесть такое количество букв не способны.
> развёрнутая статья, которая поясняет тупообезьянам, отчего их жысы-поделки всегда будут
> сосать.
> и совершенно бесполезная, потому что тупообезьяны не то, что понять — они
> и прочесть такое количество букв не способны.самое печальное, что да. я уже пару разоблачений прочитал.
I think a better title would be: “Reminder that JS is crippled on iOS.” Or something along those lines. Yup. It is. But don’t blame JavaScript. Blame Apple. They don’t want you to use JavaScript because then your code would be more portable. And that’s the last thing they want!
праздник. жыды как обычно виноваты.
ну дык. капитаню помаленьку.