JavaScript Performance Best Practices

[@r00tkit]

Почему же всё у всех по-своему… Ни к чему тут такая «индивидуальность». Придерживались бы стандартов, было бы отлично. Комментарий наверное и к посту про сохранение страниц в браузерах тоже относится.

[@TheShock]

не то окно?)

[@r00tkit]

То… Сначала туда хотел написать, потом прочитал этот пост, понял, что сюда тоже как раз. Вот так хитро и написал, чтобы не засорять базу данных хабрахабра, что может привести к излишним затратам электроэнергии.
P.S. .WWF

[@TheShock]

Простите, а к чему в этом топике «индивидуальность»? )

[@r00tkit]

И всё же я чего-то напутал) Это скорей к тому посту

[@aubt]

С последним зря вы так категоричны. Очень рекомендую книгу high performance web sites.

[@aubt]

<s>web sites</s> javascript
oreilly.com/catalog/9780596802806

[@TheShock]

Спасибо, а она отличается содержимым от High Performance Web Sites?

[@aubt]

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

[@TheShock]

Я так понимаю, вы про совет «Постарайтесь максимально избежать сообственных форматов данных и в статье показан пример такого ужаса:»?
На самом деле я не уверен, что встроенный парсер JSON, который начал появлятся в середине 2009-го года в браузерах, но уже крайне актуальный будет медленнее чьего-то «велосипедного» формата. Но спорить не буду.

На самом деле, я критически отношусь к этому вопросу больше из-за сложности поддержки, дублировании излишнего кода на сервере и клиенте.

И подозреваю, что, таки, совет не актуальный в Фоксе3.5+, Хроме, последних Операх и ИЕ8+.

[@aubt]

[].split тоже нативный. а насчет поддержки это да, но собствтвенно, оптимизация производительности это рефакторинг наоборот, поэтому поддержка усложняется сознательно.

[@TheShock]

Регекспы тоже нативные. Вопрос, что быстрее — 50 вызовов split в цикле, или один вызов json-encode

[@aubt]

я не говорю, что свое быстрее всегда. есть ситуации, где «свое» быстрее и дешевле по трафику, поэтому однозначно причислять совет к вредным не стоит, хотя в 99.9% случаев действительно лучше пользоваться стандартным форматом.

[@TheShock]

тут есть еще вопрос, почему они не сделали так:

that.contacts[n] = {
	n : contactSplit[0],
	// ...
	y : contactSplit[8]
}

[@TheShock]

что тоже есть одним из советов.

или даже так (associate из Mootools):

that.contacts[n] = contactSplit[0].associate('n', /* ... */, 'y');

Что хоть более читаемо, хоть и незначительно медленнее.

На самом деле я считаю, что советы «напишите свою хрень в 50 строк, которая возможно будет чуточку быстрее» есть однозначно вредными. Тем более, так авторитетно заявленные. Подобные вещи надо делать (а тем более советовать) предельно осторожно и когда точно знаешь, что такая «оптимизация» будет во благо, а не в зло

[@TheShock]

тем более, что такой способ не позволит передавать многие вещи аджаксом, например, если пользователь напишет:

Я устоновил игрушку в e:\cosmos\arcade\game, а она не запускается

и мы постараемся подобным запросом джсоном получить это сообщение — всё поломается. изредка, мы точно знаем формат данных, но часто такие оптимизации могут вылиться еще и кучей багов.

[@TheShock]

*не джосном а аджаксом

[@aubt]

будьте внимательнее :)
я еще раз повторю: я не говорю, что это правило, которое всегда верно. но есть ситуации, где можно передать данные своим форматом и это сэкономит 200 байт и 0,01 секунды на запрос, а в рамках какого-нибудь сервиса это 1 миллион долларов в год, что превышает издержки на поддержку такого «оптимизированного» участка кода.

[@TheShock]

абсолютно согласен с вами)

но подобные статьи рассчитаны на совершенно другой уровень разработчиков, а новички будут ошибочно считать, что JSON — должен умереть, потому что он медленный

[@TheShock]

я не утверждаю, что сплит быстрее или медленнее, я предполагаю, что это может быть мало того, что трудноподдерживаемым, так еще и не иметь смысле в силу последних изменений в браузерах

[@TedBeer]

В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.

[@TheShock]

а главного то я и не заметил. спасибо, сейчас исправлю топик

[@TedBeer]

В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.

[@r00tkit]

Вы случайно отпостили два раза с разницей в 4 минуты?

[@TheShock]

хабра глючит

[@oeiua]

был напуган

[@TedBeer]

не случайно, хабр лежал с 500й ошибкой, сделал паузу, посмотрел в соседнем окне, что коммента не появилось и попробовал еще раз и так раза 4

[@JeanLouis]

— Consider using a custom data exchange format for large datasets, as an alternative to XML and JSON

— Крайне вредный совет. Постарайтесь максимально избежать сообственных форматов данных.

Автор оригинальной статьи приводит ссылку на:
code.flickr.com/blog/2009/03/18/building-fast-client-side-searches/
где сравниваются скорость загрузки данных с помощью разных форматов и объясняется, где и когда лучше его использовать. Так что совет совсем не вредный, а гибкий, аргументированный и подкреплен примерами.

[@TheShock]

статья за March 18th, 2009. И уже неактуальна. Потому что встроенное декодирование ЖСОН появилось:
* Mozilla Firefox 3.5+ — июнь, 2009 года
* Microsoft Internet Explorer 8 — 2009 года
* Браузеры, основанные на WebKit (например, Google Chrome, Apple Safari) — я так понимаю, где-то в 2009-году, до июня
* Opera 10.5+

То есть все современные и даже многие устаревшие браузеры имеют встроенную реализацию, о которой в Марте 2009-ого было еще неизвестно.

[@JeanLouis]

Соглашусь с аргументом, но точку в этом вопросе поставят результаты актуального теста.

[@TheShock]

тесты показали, что я — неправ. сейчас обновлю топик

fx 3.5.11
json : 116ms
plain: 53ms

chrome 7.0.517.41 beta
json : 162ms
plain: 33ms

[@endshpile]

мне одному кажется что заголовок смахивает на Node.js