Каковы пределы повышения производительности JavaScript?

Question

Я занимаюсь созданием страницы прототипа за последние несколько месяцев, которая использует большое количество SVG и имеет множество элементов в целом. Существует также тонна данных, обрабатываемых как на JavaScript, так и на стороне сервера (много AJAX). На странице присутствуют тысячи слушателей событий. Это довольно тяжело, дело.

Одним из самых больших препятствий для выполнения подобных действий в JS является однопоточность, которая блокирует страницу, когда мне приходится выполнять, скажем, 10 секунд вычислений. Существуют некоторые стратегии для исправления этого, но пока веб-рабочие не поддерживаются IE, не так уж много элегантного решения. Кроме того, страница может использовать более 500 МБ памяти, с которой Chrome, похоже, время от времени сталкивается.

Что мне интересно, это возможность создания чего-то подобного в JavaScript. Мой код далеко не оптимизирован, но давайте просто предположим, что загрузка этой страницы теперь выполняется именно так, как требуется, или, скажем, требует большего.

Предположим также, что для использования приложения потребуется как минимум рабочий стол средней дальности.

Неужели люди так сильно нажимают на JavaScript? Каковы пределы того, что можно ожидать от использования памяти и производительности процессора? Сколько должно быть сделано на стороне клиента или на стороне сервера?

EDIT: Я предполагаю, что это было неизбежно, если бы каждый человек неправильно истолковал вопрос. Я не прошу совета по , как оптимизировать код JS. Я спрашиваю , сколько обработки и данных разумно обрабатывать на клиенте. ДА это зависит от аппаратного обеспечения, на которое я пытался ответить, говоря настольных компьютеров среднего класса с новейшими браузерами,, но на самом деле это не главное. Я хочу знать концептуально насколько мощным является JavaScript для тяжелой обработки. Можно ли вообще выполнять тяжелую обработку в JavaScript?

Я надеюсь, что все получат его сейчас. Это соотношение сторон сервера и клиента. Если мне нужно запустить цикл с 1000000 итерациями и ASSUMING, нет никакой стоимости в выборе между выполнением X-итераций в JS и Y-итерациях на сервере, Насколько разумно ожидать, что JavaScript будет обрабатываться?

Answer 1

Препятствие, с которым вы можете столкнуться, и на самом деле ничего не может сделать, это система, которую пользователь использует. Для пользователя, все еще использующего Pentium на 512 Мб ОЗУ, а также для добавления оскорбления к травме IE6, webapps будет измельчать. Другой проблемой является сам браузер. DOM медленный. Вы не должны касаться DOM как можно больше.

Что вы можете сделать, это улучшить свой код, найти места, которые съедают память, или слишком много обрабатывать и разрушать их. Например, однопоточная обработка может быть исправлена ​​с помощью тайм-аутов и обратных вызовов. здесь one of my demos обработка очень длинной петли. один выполняет операцию синхронизации, а другой использует таймауты для имитации асинхронной операции.

Вы также можете отключить данные и обработку на сервере, сделав клиентское приложение «тонким клиентом». Хотя HTTP-запросы могут вас убить, но вы рассматриваете ваш сервер как «второй поток», в то время как вы делаете что-то еще в своем приложении. Например, игры. Вы вычисляете оценки, рейтинги, совпадения и все на сервере. Не позволяйте стороне клиента делать это. Просто сделайте клиент «отображением» для всех вещей, которые происходят на сервере.

Answer 2

Нет ограничений, которые написаны на камне.

Что может быть сделано на моем компьютере по сравнению с машиной Я ищу рецепты по сравнению с моим 4-летним нетбуком. Память, скорость и т. Д. Зависит от браузера, процессора, бара и того, что еще работает на машине. Бьюсь об заклад, вы запустите свой код на некоторых других платформах, и он замерзнет, ​​и вам нужно будет сделать 3 пальца для того, чтобы убить процесс.

• Умная обработка событий, обнаружение кликов на более низких уровнях, а не на каждом элементе.
• Нажимайте столько, сколько сможете на сервере для интенсивной обработки.
• Оптимизируйте код, убедитесь, что вы не обновляете экран на каждой итерации цикла.
• Объедините/минимизируйте HTTP-запросы, когда это возможно.

Answer 3

1) Конечно, ваши тысячи слушателей событий можно было бы объединить через событие кипящий. Использование одного обработчика основных событий с различными подпрограммами для разных целей событий будет более результативным, чем множество специальных обработчиков.

2) «пока веб-рабочие не поддерживаются IE, не так уж много изящного решения».

Au contraire, пн frère: замораживание браузера можно смягчить, делая обработки в более мелких кусках (я стараюсь держать его под 100мсом для каждого обратного вызова, если это вообще возможно) и выполнение следующего шага после тайм-аут, который дает браузеру возможность обновить свое состояние и обработать пользовательский ввод.

3) Если у вас огромное количество элементов, это звучит как элемент HTML5 Canvas - это более подходящее решение, чем SVG.

4) «Мой код далек от оптимизировано»

алгоритмических оптимизаций сделать все различие, когда вы Раздвигая границы, как это.

5) DOM-доступ очень дорог, поэтому можно умножить огромный выигрыш , минимизирующий количество операций DOM. Убедитесь, что вы не касаетесь каждого элемента, по одному за раз. Лучше всего перестроить весь беспорядок и заменить все это на одно манипулирование DOM.