Комментарии 74
Ух, осилил.
Короче какими бы быстрыми не были нативные приложения (а это логично, я сам баловался когда-то с PHP-GTK), большинство людей будет писать веб из-за доступности к понимаю, отсутствия необходимости развиваться и себя утруждаться изучением платформы.
Я лично знаю людей, которые бралить писать приложение для Андройда с использованием позиционирования и графическими отрисовками.
Начали писать нативное — закончили для веб на JavaScript.
У всего своя ниша.
Короче какими бы быстрыми не были нативные приложения (а это логично, я сам баловался когда-то с PHP-GTK), большинство людей будет писать веб из-за доступности к понимаю, отсутствия необходимости развиваться и себя утруждаться изучением платформы.
Я лично знаю людей, которые бралить писать приложение для Андройда с использованием позиционирования и графическими отрисовками.
Начали писать нативное — закончили для веб на JavaScript.
У всего своя ниша.
в managed языках вызовы функций по умолчанию виртуальны, в то время как в C++ вызовы по умолчанию inline-ятся (от переводчика: то есть тело функции напрямую компилируется в код вместо call/ret)
Ерунда. Вместо вызова вставляется тело только для самых простых функций. В основном же используются такие же long jmp или call/ret.
Я думаю, каждый кто собрался писать приложение на основе html/js для мобильной платформы уже заранее знает что оно не будет быстрее нативного кода. Но. На андроиде большинство приложений пишутся на java и точно так же при работе проходят через JIT. Так что они тоже помедленнее нативного кода.
Смотря какой уровень оптимизации, при -O3 gcc и llvm уже вертят функции и методы как им хочется, компилятор обладает полной информацией по сайд эффектам.
Не распространяется на динамические библиотеки, там надо инлайнить ручками. Хотя там может быть LTO поможет, но не всегда.
Пишу под Windows, разницу между dll и exe не вижу в упор: и там и там PE, оба могут собраться из одинаковых объектников. Основное отличие в точке входа: в случае dll это DllMain, а в случае exe это ThreadProc. Наличие/отсутствие таблиц экспорта (exe vs dll) ни на что существенно влиять не может.
Искренне полагаю, что в случае unix'а или linux'а будет тоже самое: PE от COFF ушёл недалеко.
Так что же там такого то, что может так смущать компилятор или линкер?
Искренне полагаю, что в случае unix'а или linux'а будет тоже самое: PE от COFF ушёл недалеко.
Так что же там такого то, что может так смущать компилятор или линкер?
" На андроиде большинство приложений пишутся на java и точно так же при работе проходят через JIT."
И это весьма заметно, особенно при первом запуске.
А игры, сделанные для андроида на яве иногда так безбожно тормозят.
И это весьма заметно, особенно при первом запуске.
А игры, сделанные для андроида на яве иногда так безбожно тормозят.
От себя могу добавить про:
>НО КАК ТОГДА MONO/ANDROID/WINDOWS MOBILE УСПЕШНО СПРАВЛЯЮТСЯ С ЭТИМ?
при разработке игр (а это наверняка самые требовательные по памяти приложения), разработка идет так, чтоб GC не дергался вообще.
Для этого все объекты пихаются в пулы, где нужно используются стековые объекты, GC при вызове не имеет что чистить и отрабатывает моментально.
Освобождается память между уровнями, при лоадинге итд — тогда, когда можно.
>НО КАК ТОГДА MONO/ANDROID/WINDOWS MOBILE УСПЕШНО СПРАВЛЯЮТСЯ С ЭТИМ?
при разработке игр (а это наверняка самые требовательные по памяти приложения), разработка идет так, чтоб GC не дергался вообще.
Для этого все объекты пихаются в пулы, где нужно используются стековые объекты, GC при вызове не имеет что чистить и отрабатывает моментально.
Освобождается память между уровнями, при лоадинге итд — тогда, когда можно.
В приведенном вами разделе статьи есть ниже цитата:
Я занимался мобильными играми на Java… Лучший способ избежать сборки мусора (которая будет происходить в произвольный момент времени и убьет производительность игры) — вообще не создавать объекты в основном цикле. Другого пути нет… Только ручное управление объектами, увы. Так делают все основные высокопроизводительные игры на мобильных устройствах.
Писали же когда-то игры и для J2ME.
Как-то работало.
Не сказать чтоб это было приятно и програмеру и пользователю.
Всё внутри на статиках, в коде куча мест типа while(столько-то времени) System.GC() после загрузки данных уровня и так далее.
Тут и с нативным кодом часто упираешься в ограничение по памяти.
Приходится потом тасовать — а давай-те ка мы это пока выгрузим, загрузим то, рассчитаем что нам надо, а потом опять загрузим первое.
Но тут хоть есть уверенность, что если я сказал — выгрузить сейчас, то это будет проходить именно сейчас, а не когда-то потом, когда проснётся GC.
Ну и опять же — ретины, размеры текстур и прочего — это всё растёт, съедает туже память что и остальные данные из за этого потребление быстрее растёт, приходится более активно загружать/выгружать данные.
В нативном коде из за этого могут возникать свои проблемы — как например фрагментация памяти. Но с ней тоже можно вполне успешно и не сложно бороться.
В играх вообще, не зависимо от нейтив/менеджет стараются память не дёргать. В нейтиве просто больше шансов что без твоего ведома этого не произойдёт.
PS: Извиняюсь — кажется у меня получился не ответ а какой-то необработанный поток сознания :)
Как-то работало.
Не сказать чтоб это было приятно и програмеру и пользователю.
Всё внутри на статиках, в коде куча мест типа while(столько-то времени) System.GC() после загрузки данных уровня и так далее.
Тут и с нативным кодом часто упираешься в ограничение по памяти.
Приходится потом тасовать — а давай-те ка мы это пока выгрузим, загрузим то, рассчитаем что нам надо, а потом опять загрузим первое.
Но тут хоть есть уверенность, что если я сказал — выгрузить сейчас, то это будет проходить именно сейчас, а не когда-то потом, когда проснётся GC.
Ну и опять же — ретины, размеры текстур и прочего — это всё растёт, съедает туже память что и остальные данные из за этого потребление быстрее растёт, приходится более активно загружать/выгружать данные.
В нативном коде из за этого могут возникать свои проблемы — как например фрагментация памяти. Но с ней тоже можно вполне успешно и не сложно бороться.
В играх вообще, не зависимо от нейтив/менеджет стараются память не дёргать. В нейтиве просто больше шансов что без твоего ведома этого не произойдёт.
PS: Извиняюсь — кажется у меня получился не ответ а какой-то необработанный поток сознания :)
Почему в переводе везде APC вместо ARC? Тогда уже АПС :)
Сплю и мечтаю, что когда-нибудь можно будет скрестить быстрый layout-движок(по типу WebKit) с управляемым языком [из среды .Net, к примеру]. Потому что реализовывать интерфейс удобнее на html, а логику — на нормальных языках.
Как-то уже обсуждалось на Хабре, amenshov писал об использовании WebKit .NET:
… Но основной плюс, на мой взгляд, заключается в том, что можно иметь идентичный интерфейс на десктопе, в мобильном приложение и вебе...
Увы и ах, я капризный разработчик и не хочу тянуть за собой две «операционные системы». Если есть .NET — зачем еще и V8 грузить в память?
Ну даже если и так, ни один враппер над вебкитом пока не позволяет сделать прозрачной связи между «половинками» приложения.
Ну даже если и так, ни один враппер над вебкитом пока не позволяет сделать прозрачной связи между «половинками» приложения.
К двум «операционным системам» добавьте ещё третий фрэймворк типа ExtJS для построения интерфейса :)
Если у вас есть .NET, и вы пишете только под Windows, то можно, наверное, использовать родной WebView с движком IE, и в нём уже лепить интерфейс. О прозрачной связи я и не думал, как веб-разработчик я представлял себе «клиент-серверную» связь между половинками: интерфейс весь на HTML/JS, тяжёлая логика и хранение данных — в вашем .NET-приложении, а обмен между ними через AJAX. И вообще, я думал скорее о Node.js вместо .NET, чтобы не писать одновременно на двух языках :)
Если у вас есть .NET, и вы пишете только под Windows, то можно, наверное, использовать родной WebView с движком IE, и в нём уже лепить интерфейс. О прозрачной связи я и не думал, как веб-разработчик я представлял себе «клиент-серверную» связь между половинками: интерфейс весь на HTML/JS, тяжёлая логика и хранение данных — в вашем .NET-приложении, а обмен между ними через AJAX. И вообще, я думал скорее о Node.js вместо .NET, чтобы не писать одновременно на двух языках :)
Суть моей задумки, как раз в том, чтобы уменьшить число прослоек между интерфейсом и бизнес-логикой. Не, по такой логике можно делать еще проще: HttpListener для ядра приложения(или IIS Express + ASP.NET Web API) и любой браузер для представления.
Но это также, как и с Xorg: зачем организовывать сетевую передачу данных на локальном уровне?
Но это также, как и с Xorg: зачем организовывать сетевую передачу данных на локальном уровне?
Есть много биндингов для webkit. Только принципиального прироста в производительности, к сожалению, нет. На много эффективнее использовать комбинированный подход.
> Потому что реализовывать интерфейс удобнее на html, а логику — на нормальных языках.
QtQuick, не?
QtQuick, не?
Не, в QT работа с базами данных еще хуже, чем в Windows RT =)
> в QT
Здесь традиционный комментарий о разнице между Qt (toolkit) и QT (QuickTime).
> работа с базами данных еще хуже, чем в Windows RT
Возможно Gorthauer87 сможет что-то подсказать вам, если конечно у вас какие-либо конкретные вопросы по данной теме.
Со своей ламерской точки зрения разве что скажу, что вот гляжу я на Akonadi, и вроде вполне оно дружит хоть с MySQL, хоть с PostgreSQL.
Здесь традиционный комментарий о разнице между Qt (toolkit) и QT (QuickTime).
> работа с базами данных еще хуже, чем в Windows RT
Возможно Gorthauer87 сможет что-то подсказать вам, если конечно у вас какие-либо конкретные вопросы по данной теме.
Со своей ламерской точки зрения разве что скажу, что вот гляжу я на Akonadi, и вроде вполне оно дружит хоть с MySQL, хоть с PostgreSQL.
Интерфейсы лучше реализовывать на языках специально созданных для этого, нет?
Абсолютно согласен. Но в .NET есть два основных представителя: морально устаревший и тормознутый Windows.Forms(зато очень удобный для разработки, нет, я серьезно) и новоделанный WPF, который по всем характеристикам должен запихивать HTML5 за пояс, но, каким-то неведомым образом, умудряется работать медленнее Internet Explorer'a. Единственное, что мне не нравится в WPF — это отсутствие мало-мальски приемлемых тем для приложений. Есть MahApps.Metro, есть Elysium, есть набор портированных с сервелата «презентационных тем». Вот и все. Нормальное оформление (по типу DevExpress) будет стоить уже денег. А создавать свою тему — это довольно долгий и утомительный геморрой(учитывая все странности WPF). Вот и хочется, чтобы можно было взять «bootstrap-подобную поделку», почистить ее от кроссбраузерности и делать быстрый интерфейс с нормальным дизайном
XAML очень мощный язык, но надо уметь его готовить. Не понимая как идёт Messure всех объектов, легко написать тормознутое приложение. Часто у них всего пару строк в вёрстке поправить и все летает.
А темы, ну на нормальный дизайн всегда приходится тратиться.
А темы, ну на нормальный дизайн всегда приходится тратиться.
Спрошу тогда у Вас: лушче использовать абсолютные отступы (Windows Forms style) и один большой Grid или все же вложенные «резиновые» макеты через ColumnDefinitions/RowDefinitions?
// Я понимаю, что ответ очевидный, но интересует мнение другого человека
// Я понимаю, что ответ очевидный, но интересует мнение другого человека
Не совсем понимаю вопроса. Но чем меньше вложенность и резиновость, тем быстрее будет рисоваться. Если вы возьмете StackPanel (или лучше ListBox) и зададите ItemTemplate у которого высота нефиксированная, то эта конструкция будет рисоваться довольно медленно.
Общий совет такой: если можете уменьшить вложенность контейнеров — уменьшайте. Если можете зафиксировать размер — фиксируйте.
Grid — очень мощный контейнер. Разбивать его на три-четыре ряда(колонки), у которого 1 звёздочкой, остальные фиксированные — нормально. Нормально даже, если у ряда высота выставлена в Auto, но есть элемент в ряду, который имеет конкретный размер. Ежели у вас все ряды Auto и контент накидывается динамически, это может вызвать лаги.
Немного сумбурно рассказал, но если читать в этом направлении, должно стать понятнее msdn.microsoft.com/en-us/library/system.windows.frameworkelement.measureoverride.aspx
Общий совет такой: если можете уменьшить вложенность контейнеров — уменьшайте. Если можете зафиксировать размер — фиксируйте.
Grid — очень мощный контейнер. Разбивать его на три-четыре ряда(колонки), у которого 1 звёздочкой, остальные фиксированные — нормально. Нормально даже, если у ряда высота выставлена в Auto, но есть элемент в ряду, который имеет конкретный размер. Ежели у вас все ряды Auto и контент накидывается динамически, это может вызвать лаги.
Немного сумбурно рассказал, но если читать в этом направлении, должно стать понятнее msdn.microsoft.com/en-us/library/system.windows.frameworkelement.measureoverride.aspx
Все так, но имхо asm.js все-таки может стать серебряной пулей. Он разработан, чтобы выполняться быстро; обычный js будет в него компилироваться статически (как скажем Си компилируется в обычные машинные коды).
Один вопрос — зачем JS компилировать в asm.js, если можно его компилировать сразу в нативный код?
> обычный js будет в него компилироваться статически
Опишите, пожалуйста, как вы себе представляете эту статическую компиляцию кода на динамическом языке. Я себе могу представить разве что скомпилировать в него ещё и GC =)
Опишите, пожалуйста, как вы себе представляете эту статическую компиляцию кода на динамическом языке. Я себе могу представить разве что скомпилировать в него ещё и GC =)
Если кратко, то 4 буквы: llvm
Так в нём есть GC. llvm.org/docs/GarbageCollection.html
Я оставлю здесь ссылку, которой сегодня поделился в твиттере bobuk: blog.mozilla.org/javascript/2013/08/01/staring-at-the-sun-dalvik-vs-spidermonkey/
Это сравнение скоростей кода asm.js (запущенного в Mobile Firefox Nightly), нативного кода и dalvik-кода под андроид. Смотрите сами, кто кого рвёт как тузик грелку.
Это сравнение скоростей кода asm.js (запущенного в Mobile Firefox Nightly), нативного кода и dalvik-кода под андроид. Смотрите сами, кто кого рвёт как тузик грелку.
Я сильно подозреваю, что ценность этих тестов равна нулю. По тем же причинам, о которых упоминает автор статьи. Доводы-то те же самые: да, можно ускорить некоторые места (связанные исключительно с простыми расчетами) с помощью asm.js, но проблемы с памятью-то никуда не деваются. Как и тормоза, связанные с DOM и прочим окружением. Этот как если представить дорогу Москва-Питер со светофорами, пробками, ямами и сказать, что вот на отдельных ( и до этого прямых и быстрых участках) мы улучшили среднюю скорость проезжания с 80 до 100 км/ч. Насколько уменьшится общее время в пути, которое составляет 7 часов? Ну, минут на 15.
И еще такой момент. Какова собственно цель написания веб-приложений? Кросс-платформенность + «простота» программирования JavaScript. «Простота» с точки зрения мощности, гибкости переделок и прочих плюшек. А теперь представим себе как выглядит приложение, оптимизированное asm.js? Это такой винегрет обычного JavaScript-кода, перемешанного вставками оптимизированных кусков. Вы представляете себе сложность поддержки и развития таких приложений? Ведь это сводит на нет все преимущества JS, уж лучше сразу писать нативно…
И еще такой момент. Какова собственно цель написания веб-приложений? Кросс-платформенность + «простота» программирования JavaScript. «Простота» с точки зрения мощности, гибкости переделок и прочих плюшек. А теперь представим себе как выглядит приложение, оптимизированное asm.js? Это такой винегрет обычного JavaScript-кода, перемешанного вставками оптимизированных кусков. Вы представляете себе сложность поддержки и развития таких приложений? Ведь это сводит на нет все преимущества JS, уж лучше сразу писать нативно…
Насчет последней фразы: «лучше писать нативно». Оно-то лучше, но для скольки осей?
В качестве начальных условий — две, iOS и Android. Это абсолютный минимум. А по-хорошему бы желательно добавить WP и BlackBerry. А еще на горизонте маячат всякие убунты, файрфоксы и тайзены — и, неровен час, какая-то их них возьмет, да и взлетит?
Поддерживать такой зоопарк, имхо, совершенно нереально для небольших и даже средних компаний. Всякие там Facebook, Skype и Instagram — выкрутятся, за них беспокоиться не стоит. А остальным как быть?
В качестве начальных условий — две, iOS и Android. Это абсолютный минимум. А по-хорошему бы желательно добавить WP и BlackBerry. А еще на горизонте маячат всякие убунты, файрфоксы и тайзены — и, неровен час, какая-то их них возьмет, да и взлетит?
Поддерживать такой зоопарк, имхо, совершенно нереально для небольших и даже средних компаний. Всякие там Facebook, Skype и Instagram — выкрутятся, за них беспокоиться не стоит. А остальным как быть?
Сконцентрировать усилия там, где больше денег :)
Если у вас простое приложение, с простой веблогикой то html5+js может приемлемо работать.
Но делать фотофильтры на JS или более-менее сложную игру — вам же геморойнее будет.
Но с другой стороны можно стать и заложником технологий, что предётся потом как фесбуку переписывать с html5 своё приложение ( да ещё и сделали это так криво, что еле протолкали это в далвик )
Если у вас простое приложение, с простой веблогикой то html5+js может приемлемо работать.
Но делать фотофильтры на JS или более-менее сложную игру — вам же геморойнее будет.
Но с другой стороны можно стать и заложником технологий, что предётся потом как фесбуку переписывать с html5 своё приложение ( да ещё и сделали это так криво, что еле протолкали это в далвик )
Игры — это особая категория. Я не игроман и могу ошибаться, но… Мне кажется, что там сейчас такая конкуренция, что если игра X не выйдет на платформе Y — никто особо и не расстроится. Просто возьмут игру Z и убьют время в ней. Игры взаимозаменяемы (немного утрирую, конечно).
А вот возьмем для примера приложение-клиент к какому-то сервису/сообществу. Допустим, сервис этот весьма популярен, но к гигантам не относится. И сервис этот в каком-то смысле незаменим для пользователя. Ну например тот же Хабр — если бы ТМ решили выпустить официальный клиент под весь спектр устройств? Подозреваю, что они бы повесились. И как тут выбирать (не)приоритетные платформы?
А вот возьмем для примера приложение-клиент к какому-то сервису/сообществу. Допустим, сервис этот весьма популярен, но к гигантам не относится. И сервис этот в каком-то смысле незаменим для пользователя. Ну например тот же Хабр — если бы ТМ решили выпустить официальный клиент под весь спектр устройств? Подозреваю, что они бы повесились. И как тут выбирать (не)приоритетные платформы?
А то что на каждой платформе свой design guideline и свои требования к UX вы указать забыли? Тут никакой html5\js\etc не спасет — вам придется делать РАЗНЫЙ интерфейс под каждую платформу, и лучший это способ — реализовать на нативных элементах. А логика работы запросто делается кроссплатформенной — пишется на нативном языке C\C++, или выносится в облако в виде SaaS.
Если заказчик хочет кастомный интерфейс под кучу платформ — пускай оплатит суппорт UX под каждой платформой, а это будет стоить дорого. А если мы играем в демпинг — вот вам и веб приложения, тормоза, не соответствие design\ux guidelines и тд.
Если заказчик хочет кастомный интерфейс под кучу платформ — пускай оплатит суппорт UX под каждой платформой, а это будет стоить дорого. А если мы играем в демпинг — вот вам и веб приложения, тормоза, не соответствие design\ux guidelines и тд.
Так это, С++ везде поддерживается
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681687(v=vs.105).aspx
developer.android.com/tools/sdk/ndk/index.html
stackoverflow.com/questions/8759573/utilizing-c-in-ios-and-mac-os-x-applications
askubuntu.com/questions/259001/can-i-use-native-the-qt5-c-library-to-create-applications-for-the-phone
developer.blackberry.com/develop/platform_choice/ndk.html
Ну да, интерефейс придется, скорее всего, для каждой ОС свой делать. Ну так это в любом случае, иначе выглядеть он будет не очень.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681687(v=vs.105).aspx
developer.android.com/tools/sdk/ndk/index.html
stackoverflow.com/questions/8759573/utilizing-c-in-ios-and-mac-os-x-applications
askubuntu.com/questions/259001/can-i-use-native-the-qt5-c-library-to-create-applications-for-the-phone
developer.blackberry.com/develop/platform_choice/ndk.html
Ну да, интерефейс придется, скорее всего, для каждой ОС свой делать. Ну так это в любом случае, иначе выглядеть он будет не очень.
Вы просто не понимаете, что вообще такое есть asm.js.
Взяли прогу на любом, в принципе, языке, но допустим на обычном js.
Сунули её в компилятор asm.js, который сделал полный статический анализ программы. На выходе мы получили низкоуровневую кашу, для исполнения которой не нужны динамические типы, не нужна сборка мусора, не нужны классы-обертки, рантайм-проверки и пр. Все, что там есть — это числа, строки, функции и структуры в стиле Си. Соответственно, знающий про asm.js jit-компилятор в браузере может исполнять эту кашу очень быстро, так как отсутствуют все перечисленные в этой статье проблемы с производительностью.
Но при этом, это все еще javascript, который можно скормить какому-нибудь ИЕ.
А на этапе отладки вы просто ничего не компилируете и работаете с исходным js-кодом.
Взяли прогу на любом, в принципе, языке, но допустим на обычном js.
Сунули её в компилятор asm.js, который сделал полный статический анализ программы. На выходе мы получили низкоуровневую кашу, для исполнения которой не нужны динамические типы, не нужна сборка мусора, не нужны классы-обертки, рантайм-проверки и пр. Все, что там есть — это числа, строки, функции и структуры в стиле Си. Соответственно, знающий про asm.js jit-компилятор в браузере может исполнять эту кашу очень быстро, так как отсутствуют все перечисленные в этой статье проблемы с производительностью.
Но при этом, это все еще javascript, который можно скормить какому-нибудь ИЕ.
А на этапе отладки вы просто ничего не компилируете и работаете с исходным js-кодом.
Это половина правды. Другая половина заключается в том, что для оптимизации кода он должен удовлетворять определенным ограничениям. В которых собака и зарылась. И которые сводят все преимущества динамического языка на нет.
>Взяли прогу на любом, в принципе, языке, но допустим на обычном js.
>Сунули её в компилятор asm.js, который сделал полный статический анализ программы.
А что по-вашему тогда JIT делает? =) И почему «компилятор asm.js» и «знающий про asm.js jit-компилятор» внезапно будет это лучше делать?
>Сунули её в компилятор asm.js, который сделал полный статический анализ программы.
А что по-вашему тогда JIT делает? =) И почему «компилятор asm.js» и «знающий про asm.js jit-компилятор» внезапно будет это лучше делать?
JIT-компилятор сильно ограничен во времени, иначе время «jit-компиляции» будет больше времени исполнения. Поэтому полный анализ кода ему недоступен. Отдельный компилятор же таких ограничений лишен и может спокойно выяснить, например, что такая-то переменная всегда число, или такая-то функция захватывает вот эти две переменные таких-то типов (и их можно ввести в структуру this) и т.п. и т.д.
Статическая компиляция — не панацея. JIT-компилятор может собирать профиль и перекомпиливать метод. JIT-оптимизатор может делать агрессивные оптимизации, делая довольно-таки смелые предположения, и потом перекомпилировать методы, если предположения не оправдались. Статический компилятор вынужден быть консервативным.
А вот если в asm.js скомпилить какой-нибудь C, то можно и кодек написать, и рендерер.
А вот если в asm.js скомпилить какой-нибудь C, то можно и кодек написать, и рендерер.
Ценность этих тестов нулевая. К примеру гениальное объяснение почему деревья на asm.js быстрее нативного
Т.е. они не умеют работать с аллокатором памяти на болшом кол-ве обращений к нему и ругают нативный код? эх, если уж на то пошло — взяли бы 3х лучших инженеров из JS, Native, Dalvik и одни и те же тесты попросили их выполнить максимально быстро — вот тогда еще хоть что-то можно сравнивать, но тогда результаты не понравяться тем кто заказывает такие «красивые графики».
Notice that binary-trees allocates a lot of objects. In C++, this causes many calls to malloc. When compiled to native code, the malloc implementation occasionally uses expensive system calls to allocate new memory from the system.
Т.е. они не умеют работать с аллокатором памяти на болшом кол-ве обращений к нему и ругают нативный код? эх, если уж на то пошло — взяли бы 3х лучших инженеров из JS, Native, Dalvik и одни и те же тесты попросили их выполнить максимально быстро — вот тогда еще хоть что-то можно сравнивать, но тогда результаты не понравяться тем кто заказывает такие «красивые графики».
Т.к. в asm.js нет управления памяти вообще (а есть только возможность писать в заранее выделенные байтовые массивы), то, по сути, нужно его ещё написать в виде библиотеки. Подозреваю, что где-то он там и зарыт — то ли свой написан для конкретного трансформера в asm.js, то ли трансформер берёт какой-нибудь LLVM-код стандартной библиотеки C и оттуда просто вкомпиливает в программу код malloc и free. Почему в случае asm.js получилось даже быстрее — вопрос отдельный.
Почему веб-приложения на мобильных платформах работают медленно
Потому, что весь стек веб технологий тормозное говно?!
Потому, что весь стек веб технологий тормозное говно?!
В статье уже есть момент про клуб тавтологии.
ну зачем сразу про стек…
момоему если мы апплик(флэш или джава) запускаем в браузере(хром например) который запущен в ОС(Убунту например) запущенную понятное дело на какойто аппаратной платформе имеем тройное заложение уровней трансляции комманд как минимум.Если есть по дороге скачки битности — то только хуже становится. Плюс геморрой с засёром памяти.
Это как три шестеренки подряд. Потери всегда будут и КПД никогда небудет в 100%. То что в лучае описанного стека шестеренки кривые и весьма параноидальной формы — только ухудшает и без того небезоблачную ситуацию.
момоему если мы апплик(флэш или джава) запускаем в браузере(хром например) который запущен в ОС(Убунту например) запущенную понятное дело на какойто аппаратной платформе имеем тройное заложение уровней трансляции комманд как минимум.Если есть по дороге скачки битности — то только хуже становится. Плюс геморрой с засёром памяти.
Это как три шестеренки подряд. Потери всегда будут и КПД никогда небудет в 100%. То что в лучае описанного стека шестеренки кривые и весьма параноидальной формы — только ухудшает и без того небезоблачную ситуацию.
Большая проблема производительности JS, как мне кажется, не сборка мусора, а динамический диспатч методов. Чтобы вызвать метод/функцию, нужно взять объект, взять его внутреннюю хэш-таблицу с отображением атрибутов, произвести там поиск по строке (типа strcmp), потом уже вызвать код. И закешировать ничего нормально нельзя, так как атрибуты объекта теоретически могут измениться в любое время, таково уж свойство динамических языков. И так повторяется много раз. В других языках (C++, Java, да и C# наверное) диспатч происходит не по строке, а по некоему указателю/хэндлеру, которых может уместиться в int (в крайнем случае в long). Разные оптимизации и JIT в JS могут помогать, но не сильно.
А вот это неправда. Все современные JS-движки строят внутри себя скрытые классы, которые автоматом генерируются, когда в какому-то объекту в рантайме добавляется свойство. А дальше применяется целая куча оптимизаций, которые позволяют свести вызовы к virtual table, а иногда вообще к абсолютным call'ам или даже заинлайнить.
Аналогия из мира приложений, работающими с СУБД: автор приложения, разрабатывая его, часто работает с плохо отстроенным СУБД, думая при этом, что для отладки хватает, а в реальном мире администратор настроит сервера как надо. Администратор при работе с ПО, в свою очередь, рассуждает, что приложение писали под решение задач, раз не ругается на СУБД, значит, с ней все нормально. И обе стороны (ПО и СУБД) функционируют неоптимально, поскольку программист не знает, что рекомендовать для настройки СУБД (он не спец по ней), а администратор при внедрении всего комплекса может полагаться только на свои догадки.
С JS та же история: те, кто пишут движки в браузерах, для понимания прогресса в работе используют бенчмарки. В жизни эти сферические попугаи не дают ответа на вопрос, быстро ли в браузере будет работать то или иное веб-приложение, но тестировать браузер работой конкретной веб-разработки как-то несколько однобоко. Опять полагаемся на везение и то, что браузер «подойдет» к веб-приложению. Жуть!
С JS та же история: те, кто пишут движки в браузерах, для понимания прогресса в работе используют бенчмарки. В жизни эти сферические попугаи не дают ответа на вопрос, быстро ли в браузере будет работать то или иное веб-приложение, но тестировать браузер работой конкретной веб-разработки как-то несколько однобоко. Опять полагаемся на везение и то, что браузер «подойдет» к веб-приложению. Жуть!
Отличная статья, только примеры чуть-чуть неудачные имхо: как раз пример с фотографиями/кадрами и сборщиком мусора мне кажется притянутым за уши. Я не совсем в теме мобильных приложений и графики, но подозреваю, что куча больших буферов одинакового размера будет примерно одинаково хорошо/плохо в плане производительности и оверхеда работать как с malloc/free, так и со сборщиком мусора. Malloc/free или, что примерно то же самое, ARC тоже не идеальны и возможно даже чуть более подвержены фрагментации, с которой надо отдельно бороться.
Равно как и алгоритмы обработки картинок (например, автоматическая яркость/контраст или резкость для фотографии), как мне кажется, как раз можно дооптимизировать до сравнимого с нативной производительностью (если не рассматривать рукописный код на ассемблере с SIMD), например с помощью упомянутого asm.js. Там ведь в идеале даже от оверхеда «виртуальных функций» можно избавиться, правильно пиля код на функции.
Но оба тезиса сразу теряют силу как только мы начинаем говорить о других видах приложений, не занимающихся хранением и обработкой больших монолитных кусков данных.
Равно как и алгоритмы обработки картинок (например, автоматическая яркость/контраст или резкость для фотографии), как мне кажется, как раз можно дооптимизировать до сравнимого с нативной производительностью (если не рассматривать рукописный код на ассемблере с SIMD), например с помощью упомянутого asm.js. Там ведь в идеале даже от оверхеда «виртуальных функций» можно избавиться, правильно пиля код на функции.
Но оба тезиса сразу теряют силу как только мы начинаем говорить о других видах приложений, не занимающихся хранением и обработкой больших монолитных кусков данных.
Скорость JS-кода совсем не важна. Главная проблема — отзывчивость интерфейса.
Если интерфейс будет быстр, а во время обработки будет показываться честный прогресс-бар, то пользователь не заметит проблем. Это как хаотичная очередь в старом Сбербанке и современная с номером на бумажке — честная и предсказуемая может работать медленнее хаотичной, но всё равно больше понравится пользователю.
То есть я согласен, что проблема с производительностью веб-приложений есть. Но она совершенно в другом месте — в CSS, отрисовке, фреймах. А не в сухой математике тестов. Например, хорошие анимации работают только через CSS Animation или CSS Transition — они даже не вызывают JS-кода. Но именно лаги анимации создают ощущение медленного интерфейса.
Если интерфейс будет быстр, а во время обработки будет показываться честный прогресс-бар, то пользователь не заметит проблем. Это как хаотичная очередь в старом Сбербанке и современная с номером на бумажке — честная и предсказуемая может работать медленнее хаотичной, но всё равно больше понравится пользователю.
То есть я согласен, что проблема с производительностью веб-приложений есть. Но она совершенно в другом месте — в CSS, отрисовке, фреймах. А не в сухой математике тестов. Например, хорошие анимации работают только через CSS Animation или CSS Transition — они даже не вызывают JS-кода. Но именно лаги анимации создают ощущение медленного интерфейса.
Если C-программа выполняется за 10 мс, то 50 мс программа на JS может считаться «сравнимой». Но если C-приложение занимает 10 сек, то 50 сек JS приложение для большинства уже несравнимо с ним.
Как по мне, то не очень удачный пример. Несравнимы, по-моему, цифры порядка 1-3 секунды и 5-15. Меньше нескольких секунд особо будут незаметны, особенно при наличии реалистичных прогресс-баров, а начиная с порядка 10 секунд «заставляют» убирать фокус внимания с приложения.
А вообще основная проблема по моему дилетантскому мнению в динамической типизации. Особенно при работе с массивами (вернее хэш-таблицами) и объектами. В языках со статической типизацией транслятор заранее знает сколько памяти нужно выделить под сущность и размер этого куска памяти ему в дальнейшем изменять не приходится. Для JS же характерно создание элементов сущностей по мере необходимости, то есть постоянный вызов где-то внутри движка realloc или его аналогов. Возможно проблему хотя бы частично решит некое подмножество JS или просто следование соглашениям типа «сначала объявляется всё что нужно и лишь потом используется», «руками разбивать циклические ссылки» и «не менять тип сущностей во время исполнения». Ну и ручное управление gc (разрешить, запретить, запустить цикл очистки) наверное не сложно ввести.
Респект переводчику. Как представлю, сколько времени и сил надо было потратить на это…
При этом количество вакансий на js-разработчиков, умеющих мобильный веб — растут как на дрожжах.
Эм PoP применять стали совсем не давно и если посмотреть многие устройства имеют отдельные модули памяти не на процессоре, так что как минимум один слабый аргумент я вижу.
JavaScript изначально не предназначался для создания мобильных приложений.
В целом — www.youtube.com/watch?v=clKi92j6eLE
В целом — www.youtube.com/watch?v=clKi92j6eLE
Давно об этом спрашивал — зачем писать на js игры, приложения и даже операционные системы, если оно всё тормозит…
Отличная статья!
Отличная статья!
Не хотел бы никого обидеть, но что то мне подсказывает, что без целенаправленного возможно заказного пиара нативного программирования в этой статье не обошлось.
Потому как
1) тут одностороннее утверждение — «только так и не иначе»
2) свидетельства «инженеров» взятые из желтой прессы. Где ссылки на конкретные исследования проведенные над архитектурой процессоров и зависимость от этого их скоростей??? — нет такого, т к научная литература намного недоступнее чем желтая пресса. А в наше время почему-то вошло в моду цитировать распиаренные «догматы» из желтой прессы, безоговорочно уповая на их истину.
3) Почему желтая пресса это плохо и в нее нельзя верить? Потому как желтая пресса в наше время — это инструмент пропаганды, который настроен на формирование определенного мнения в массах.
4) Почему выгодно пиарить нативное программирование? Да потому что, один из столпов на чем держится современная экономика и в частности IT индустрия — это РАЗДЕЛЕНИЕ ТРУДА. Поэтому не выгодно когда есть «фока на все руки дока», который может самостоятельно сварганить к примеру сайт на пхп по сути не хуже чем его делают целые студии за цены в десятки раз большие и усилиями трудочасами также большими в разы а то и в десятки. Потому нужно как-то заставить денежную массу крутиться более мощным потоком, повысив себистоимость разработки и количество вовлеченного персонала — сливки то увеличиваются в разы для тех кто сидит сверху. Так и тут чтобы сделать нативное мультиплатформенное приложение — нужно условно сказать «под каждый девайс свой язык».
5) Ну и еще — рискую изменением рейтинга в не лучшую сторону, что гоню на желтую прессу и современные столпы экономики, но это и будет плюсик в пользу того что мысль моя истинна.
Потому как
1) тут одностороннее утверждение — «только так и не иначе»
2) свидетельства «инженеров» взятые из желтой прессы. Где ссылки на конкретные исследования проведенные над архитектурой процессоров и зависимость от этого их скоростей??? — нет такого, т к научная литература намного недоступнее чем желтая пресса. А в наше время почему-то вошло в моду цитировать распиаренные «догматы» из желтой прессы, безоговорочно уповая на их истину.
3) Почему желтая пресса это плохо и в нее нельзя верить? Потому как желтая пресса в наше время — это инструмент пропаганды, который настроен на формирование определенного мнения в массах.
4) Почему выгодно пиарить нативное программирование? Да потому что, один из столпов на чем держится современная экономика и в частности IT индустрия — это РАЗДЕЛЕНИЕ ТРУДА. Поэтому не выгодно когда есть «фока на все руки дока», который может самостоятельно сварганить к примеру сайт на пхп по сути не хуже чем его делают целые студии за цены в десятки раз большие и усилиями трудочасами также большими в разы а то и в десятки. Потому нужно как-то заставить денежную массу крутиться более мощным потоком, повысив себистоимость разработки и количество вовлеченного персонала — сливки то увеличиваются в разы для тех кто сидит сверху. Так и тут чтобы сделать нативное мультиплатформенное приложение — нужно условно сказать «под каждый девайс свой язык».
5) Ну и еще — рискую изменением рейтинга в не лучшую сторону, что гоню на желтую прессу и современные столпы экономики, но это и будет плюсик в пользу того что мысль моя истинна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему веб-приложения на мобильных платформах работают медленно