13.11.2011, 21:08
|
Новичок на форуме
|
|
Регистрация: 11.10.2011
Сообщений: 8
|
|
компиляция JavaScript
Добрый день, господа.
Меня мучает не конкретный, а скорее абстрактный вопрос по которому я хотел бы услышать ваше мнение.
Вопрос такой - почему на ваш взгляд браузеры не могут ввести функцию компиляции javascript-кода?
Опишу ситуацию, чтобы было понятнее: у меня на сайте есть анимация и другие подобные эффекты, реализованные с помощью JS. Но когда я открываю сайт на старых компьютерах, или на мобильных устройствах, эффекты начинают дико тормозить, ХОТЯ, если написать любое компилируемое приложение, например на C++ под винду, оперирующее теми же ресурсами (картинками и текстом) и выполняющее на вид точно такие же действия, то естественно, запустив это приложение на слабом компе, тормозов там не будет. При этом компилируется приложение достаточно быстро (неск.секунд).
Так почему браузер не может после загрузки страницы, скомпилировать JS в машинный код и запустить его в своем окне?
Да, у скомпилированного кода есть плюсы и минусы в сравнении со скриптовым. Основной плюс - значительное быстродействие, минусы: 1) программу можно будет запустить только после того, как она полностью скачается и скомпилируется. 2) скриптовый код может в реальном времени модифицироваться.
Но в некоторых случаях последние два пункта не важны для сайта (веб-приложения), а важна лишь скорость выполнения кода. Можно было бы например в заголовках страницы указывать, использовать ли браузеру компиляцию, или выполнять как скрипт.
Мне кажется это было бы крайне удобно. Так что же останавливает производителей браузеров?
|
|
13.11.2011, 21:18
|
|
Матрос
|
|
Регистрация: 04.04.2008
Сообщений: 6,246
|
|
Сообщение от jimm88
|
2) скриптовый код может в реальном времени модифицироваться.
Но в некоторых случаях последние два пункта не важны для сайта (веб-приложения), а важна лишь скорость выполнения кода.
|
самомодификация кода не такой уж ненужный момент
Сообщение от jimm88
|
Так что же останавливает производителей браузеров?
|
может то, что реализация компилятора требует не меньших ресурсов времени и людей, чем реализация интепретатора?!
Может потому что то небольшое количество неплатежеспособного населения, что сидит на слабых компах.
так, вот может потому что то небольшое количество бедняков за несколько лет разработки станет еще меньше?
И потому, что эти затраты не окупятся
|
|
13.11.2011, 22:03
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от jimm88
|
у меня на сайте есть анимация и другие подобные эффекты
|
JavaScript в анимации не тормозит. Тормозит рендеринг, которым занимается сам браузер, который и так откомпилирован. Так что компиляция вам не поможет.
|
|
13.11.2011, 22:11
|
Новичок на форуме
|
|
Регистрация: 11.10.2011
Сообщений: 8
|
|
Цитата:
|
самомодификация кода не такой уж ненужный момент
|
Я не говорю, что он не нужный, я говорю что иногда он нужный, а иногда им можно пожертвовать в пользу быстродействия. Главное, чтобы у программиста была возможность выбора.
Цитата:
|
...требует ресурсов времени и людей
|
Ресурсы у проиводителей браузеров есть. Уж какой только ерунды они в браузер не пихают.
Цитата:
|
небольшое количество неплатежеспособного населения, что сидит на слабых компах
|
Тут вы ошибаетесь. С каждым днем количество "слабых" компов в сети стремительно увеличивается, если отнести к слабым компам планшетники, нетбуки и коммуникаторы. А ведь на них как раз таки и тормозят большинство сайтов, напичканных различной JS-анимацией.
|
|
13.11.2011, 22:27
|
Новичок на форуме
|
|
Регистрация: 11.10.2011
Сообщений: 8
|
|
Сообщение от Kolyaj
|
JavaScript в анимации не тормозит. Тормозит рендеринг
|
Боюсь, что и вы ошибаетесь, Kolyaj.
Объясните тогда мне, как так получается, что моя прога на С++, которая перемещает jpeg-картинку по окну не тормозит на процессоре Atom, а ТАЖЕ САМАЯ jpeg картинка которую я перемещаю по окну с помощью JS в браузере тормозит.
Или вы хотите сказать, что я использую более продвинутые методы рендеринга, чем производители браузеров?
Боюсь, что дело все-таки в компиляции..
|
|
13.11.2011, 22:36
|
|
Матрос
|
|
Регистрация: 04.04.2008
Сообщений: 6,246
|
|
Сообщение от jimm88
|
Уж какой только ерунды они в браузер не пихают.
|
аха.
и теперь на каждую "ерунду"(которая объективно отношения к JS никакого не имеет) они должны тратить в два или более раз времени больше, чтобы написать еще и компилируемую версию.
Плюс не забываем, что уже существующий функционал также надо сделать в компилируемой версии. А это значит несколько лет, в течении которых программисты будут трудится не давая какого-то результата(всмысле релиза), и даже дав его, он принесет денег ну крайне мало, что даже им на зарплату не хватит.
Сообщение от jimm88
|
Тут вы ошибаетесь. С каждым днем количество "слабых" компов в сети стремительно увеличивается, если отнести к слабым компам планшетники, нетбуки и коммуникаторы.
|
ну, если вы их считаете слабыми, то лажно...
А я считаю, что под их железо вполне можно писать адекватные сайты, если стоит такая цель.
Другой вопрос, что 90 % заказчиков не требуется написание сайта, "чтобы не тормозил на афоне", и при этом они не готовы платить даже средн ие деньги за данную работу. Поэтому и делается безграмотное говно школьниками за минимальную оплату.
99% нужд веб-а, грамотный специалист(при условии что ему адекватно заплатят) сможет реализовать, что они не будут тормозить на 600 и даже меньше МГц Хотя и остается 1% весьма специфичных задач.
Это не так уж трудно, и вполне реально, ИМХО.
Другой вопрос, когда сайт заказывается за 50-150 баксов школьнику. Тут о качестве совсем другой разговор.
Поэтому и делают дилетанты ширптортеб.
а с чего бы ширпотребу быть качественным? он таким не должен быть
|
|
13.11.2011, 22:37
|
sinistral
|
|
Регистрация: 28.03.2011
Сообщений: 5,418
|
|
потому что js выше, чем С++.
сравните вычисления C++ и asm. {trollface}
|
|
13.11.2011, 22:39
|
Новичок на форуме
|
|
Регистрация: 19.02.2008
Сообщений: 9,177
|
|
Сообщение от jimm88
|
Объясните тогда мне, как так получается, что моя прога на С++, которая перемещает jpeg-картинку по окну не тормозит на процессоре Atom, а ТАЖЕ САМАЯ jpeg картинка которую я перемещаю по окну с помощью JS в браузере тормозит.
|
Это что ж у вас за анимация такая, что банальное передвижение картинки тормозит?
|
|
13.11.2011, 22:43
|
|
Матрос
|
|
Регистрация: 04.04.2008
Сообщений: 6,246
|
|
Сообщение от jimm88
|
Или вы хотите сказать, что я использую более продвинутые методы рендеринга, чем производители браузеров?
|
А если подумать, и немного включить мозг?
Когда ты на с++ двигаешь картинку, то ты двигаешь только ее.
когда ты делаешь это в браузере, то ее движение затрагивает также всех потомков,и соседей ее, и каждлого из потомков. как минимум.
Не считаюа перерисовик объектов поверх, и перед объектом. А это еще огромное количество потомков и соседей.
В результате для сотен-тысяч объектов производится куча вычислений, для того чтобы сдвинуть один объект.
Не будем забывать, что каждый из объектов характеризуется не только размерами, но и еще кучей CSS-свойств, котоыре взаимодействуют с остальными объектами. то есть даже один на один объект, в браузере требуется больше вычислений.
Ну, и напоследок не будем забывать, что ко всей этой куче медленных операций JS не имеет ни малейшего отношения, и компилируя его добится ускорения тут не поулчится
|
|
13.11.2011, 22:44
|
Профессор
|
|
Регистрация: 04.02.2011
Сообщений: 1,815
|
|
Кто сказал что не компилируют.
1)V8 компилирует код. Точнее там механизм компиляции кода на лету.
2) firefox также компилирует код при помощи tracemonkie уже c 2009 года, это версия 3.5.
с версии 4, также появилась компиляция на лету (проект JaegerMonkey).
JavaScript- вполне сносно справляется даже с 3D графикой, полно 3d движков. Дури много, а тормозит именно рендеринг DOM . Другое дело что javascript не совсем подходит для компиляции. Аналогичный код на c++ всё равно производительнее. Эту проблему можно решить только заменив javaScript другим более строгим языком, что гугл уже во второй раз пытается сделать.
__________________
Лучше калымить в гандурасе чем гандурасить на колыме
Последний раз редактировалось DjDiablo, 13.11.2011 в 23:13.
|
|
|
|