Pull to refresh

Comments 32

Почему же всё у всех по-своему… Ни к чему тут такая «индивидуальность». Придерживались бы стандартов, было бы отлично. Комментарий наверное и к посту про сохранение страниц в браузерах тоже относится.
То… Сначала туда хотел написать, потом прочитал этот пост, понял, что сюда тоже как раз. Вот так хитро и написал, чтобы не засорять базу данных хабрахабра, что может привести к излишним затратам электроэнергии.
P.S. .WWF
Простите, а к чему в этом топике «индивидуальность»? )
И всё же я чего-то напутал) Это скорей к тому посту
С последним зря вы так категоричны. Очень рекомендую книгу high performance web sites.
да, в ней описано больше техник оптимизации. по сути в hpws в разделах, посвященных javascript есть только отрывки из первой. и, главное, донесено что именно нужно оптимизировать, а что нет.
Я так понимаю, вы про совет «Постарайтесь максимально избежать сообственных форматов данных и в статье показан пример такого ужаса:»?
На самом деле я не уверен, что встроенный парсер JSON, который начал появлятся в середине 2009-го года в браузерах, но уже крайне актуальный будет медленнее чьего-то «велосипедного» формата. Но спорить не буду.

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

И подозреваю, что, таки, совет не актуальный в Фоксе3.5+, Хроме, последних Операх и ИЕ8+.
[].split тоже нативный. а насчет поддержки это да, но собствтвенно, оптимизация производительности это рефакторинг наоборот, поэтому поддержка усложняется сознательно.
Регекспы тоже нативные. Вопрос, что быстрее — 50 вызовов split в цикле, или один вызов json-encode
я не говорю, что свое быстрее всегда. есть ситуации, где «свое» быстрее и дешевле по трафику, поэтому однозначно причислять совет к вредным не стоит, хотя в 99.9% случаев действительно лучше пользоваться стандартным форматом.
тут есть еще вопрос, почему они не сделали так:

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


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

или даже так (associate из Mootools):
that.contacts[n] = contactSplit[0].associate('n', /* ... */, 'y');

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

На самом деле я считаю, что советы «напишите свою хрень в 50 строк, которая возможно будет чуточку быстрее» есть однозначно вредными. Тем более, так авторитетно заявленные. Подобные вещи надо делать (а тем более советовать) предельно осторожно и когда точно знаешь, что такая «оптимизация» будет во благо, а не в зло
тем более, что такой способ не позволит передавать многие вещи аджаксом, например, если пользователь напишет:
Я устоновил игрушку в e:\cosmos\arcade\game, а она не запускается
и мы постараемся подобным запросом джсоном получить это сообщение — всё поломается. изредка, мы точно знаем формат данных, но часто такие оптимизации могут вылиться еще и кучей багов.
будьте внимательнее :)
я еще раз повторю: я не говорю, что это правило, которое всегда верно. но есть ситуации, где можно передать данные своим форматом и это сэкономит 200 байт и 0,01 секунды на запрос, а в рамках какого-нибудь сервиса это 1 миллион долларов в год, что превышает издержки на поддержку такого «оптимизированного» участка кода.
абсолютно согласен с вами)

но подобные статьи рассчитаны на совершенно другой уровень разработчиков, а новички будут ошибочно считать, что JSON — должен умереть, потому что он медленный
я не утверждаю, что сплит быстрее или медленнее, я предполагаю, что это может быть мало того, что трудноподдерживаемым, так еще и не иметь смысле в силу последних изменений в браузерах
В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
а главного то я и не заметил. спасибо, сейчас исправлю топик
В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
Вы случайно отпостили два раза с разницей в 4 минуты?
не случайно, хабр лежал с 500й ошибкой, сделал паузу, посмотрел в соседнем окне, что коммента не появилось и попробовал еще раз и так раза 4
— 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/
где сравниваются скорость загрузки данных с помощью разных форматов и объясняется, где и когда лучше его использовать. Так что совет совсем не вредный, а гибкий, аргументированный и подкреплен примерами.
статья за March 18th, 2009. И уже неактуальна. Потому что встроенное декодирование ЖСОН появилось:
* Mozilla Firefox 3.5+ — июнь, 2009 года
* Microsoft Internet Explorer 8 — 2009 года
* Браузеры, основанные на WebKit (например, Google Chrome, Apple Safari) — я так понимаю, где-то в 2009-году, до июня
* Opera 10.5+

То есть все современные и даже многие устаревшие браузеры имеют встроенную реализацию, о которой в Марте 2009-ого было еще неизвестно.
Соглашусь с аргументом, но точку в этом вопросе поставят результаты актуального теста.
тесты показали, что я — неправ. сейчас обновлю топик
fx 3.5.11
json : 116ms
plain: 53ms

chrome 7.0.517.41 beta
json : 162ms
plain: 33ms
мне одному кажется что заголовок смахивает на Node.js
Sign up to leave a comment.

Articles