Comments 32
Почему же всё у всех по-своему… Ни к чему тут такая «индивидуальность». Придерживались бы стандартов, было бы отлично. Комментарий наверное и к посту про сохранение страниц в браузерах тоже относится.
0
С последним зря вы так категоричны. Очень рекомендую книгу high performance web sites.
+1
<s>web sites</s> javascript
oreilly.com/catalog/9780596802806
oreilly.com/catalog/9780596802806
+1
Спасибо, а она отличается содержимым от High Performance Web Sites?
+1
Я так понимаю, вы про совет «Постарайтесь максимально избежать сообственных форматов данных и в статье показан пример такого ужаса:»?
На самом деле я не уверен, что встроенный парсер JSON, который начал появлятся в середине 2009-го года в браузерах, но уже крайне актуальный будет медленнее чьего-то «велосипедного» формата. Но спорить не буду.
На самом деле, я критически отношусь к этому вопросу больше из-за сложности поддержки, дублировании излишнего кода на сервере и клиенте.
И подозреваю, что, таки, совет не актуальный в Фоксе3.5+, Хроме, последних Операх и ИЕ8+.
На самом деле я не уверен, что встроенный парсер JSON, который начал появлятся в середине 2009-го года в браузерах, но уже крайне актуальный будет медленнее чьего-то «велосипедного» формата. Но спорить не буду.
На самом деле, я критически отношусь к этому вопросу больше из-за сложности поддержки, дублировании излишнего кода на сервере и клиенте.
И подозреваю, что, таки, совет не актуальный в Фоксе3.5+, Хроме, последних Операх и ИЕ8+.
+1
[].split тоже нативный. а насчет поддержки это да, но собствтвенно, оптимизация производительности это рефакторинг наоборот, поэтому поддержка усложняется сознательно.
0
Регекспы тоже нативные. Вопрос, что быстрее — 50 вызовов split в цикле, или один вызов json-encode
+1
я не говорю, что свое быстрее всегда. есть ситуации, где «свое» быстрее и дешевле по трафику, поэтому однозначно причислять совет к вредным не стоит, хотя в 99.9% случаев действительно лучше пользоваться стандартным форматом.
0
тут есть еще вопрос, почему они не сделали так:
that.contacts[n] = {
n : contactSplit[0],
// ...
y : contactSplit[8]
}
+1
что тоже есть одним из советов.
или даже так (associate из Mootools):
Что хоть более читаемо, хоть и незначительно медленнее.
На самом деле я считаю, что советы «напишите свою хрень в 50 строк, которая возможно будет чуточку быстрее» есть однозначно вредными. Тем более, так авторитетно заявленные. Подобные вещи надо делать (а тем более советовать) предельно осторожно и когда точно знаешь, что такая «оптимизация» будет во благо, а не в зло
или даже так (associate из Mootools):
that.contacts[n] = contactSplit[0].associate('n', /* ... */, 'y');
Что хоть более читаемо, хоть и незначительно медленнее.
На самом деле я считаю, что советы «напишите свою хрень в 50 строк, которая возможно будет чуточку быстрее» есть однозначно вредными. Тем более, так авторитетно заявленные. Подобные вещи надо делать (а тем более советовать) предельно осторожно и когда точно знаешь, что такая «оптимизация» будет во благо, а не в зло
+1
тем более, что такой способ не позволит передавать многие вещи аджаксом, например, если пользователь напишет:
Я устоновил игрушку в e:\cosmos\arcade\game, а она не запускаетсяи мы постараемся подобным запросом джсоном получить это сообщение — всё поломается. изредка, мы точно знаем формат данных, но часто такие оптимизации могут вылиться еще и кучей багов.
+1
*не джосном а аджаксом
+1
будьте внимательнее :)
я еще раз повторю: я не говорю, что это правило, которое всегда верно. но есть ситуации, где можно передать данные своим форматом и это сэкономит 200 байт и 0,01 секунды на запрос, а в рамках какого-нибудь сервиса это 1 миллион долларов в год, что превышает издержки на поддержку такого «оптимизированного» участка кода.
я еще раз повторю: я не говорю, что это правило, которое всегда верно. но есть ситуации, где можно передать данные своим форматом и это сэкономит 200 байт и 0,01 секунды на запрос, а в рамках какого-нибудь сервиса это 1 миллион долларов в год, что превышает издержки на поддержку такого «оптимизированного» участка кода.
0
я не утверждаю, что сплит быстрее или медленнее, я предполагаю, что это может быть мало того, что трудноподдерживаемым, так еще и не иметь смысле в силу последних изменений в браузерах
+1
В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
+2
В заголовке указана категория WRT (Nokia Web Runtime or Widget for S60)
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
Т.е. речь про конкретную нокиевскую платформу, а не общие рекомендации для всех случаев.
Там может и JSON тормозит и нету jit и другие прелести мобильной платформы.
+1
— 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/
где сравниваются скорость загрузки данных с помощью разных форматов и объясняется, где и когда лучше его использовать. Так что совет совсем не вредный, а гибкий, аргументированный и подкреплен примерами.
— Крайне вредный совет. Постарайтесь максимально избежать сообственных форматов данных.
Автор оригинальной статьи приводит ссылку на:
code.flickr.com/blog/2009/03/18/building-fast-client-side-searches/
где сравниваются скорость загрузки данных с помощью разных форматов и объясняется, где и когда лучше его использовать. Так что совет совсем не вредный, а гибкий, аргументированный и подкреплен примерами.
0
статья за March 18th, 2009. И уже неактуальна. Потому что встроенное декодирование ЖСОН появилось:
* Mozilla Firefox 3.5+ — июнь, 2009 года
* Microsoft Internet Explorer 8 — 2009 года
* Браузеры, основанные на WebKit (например, Google Chrome, Apple Safari) — я так понимаю, где-то в 2009-году, до июня
* Opera 10.5+
То есть все современные и даже многие устаревшие браузеры имеют встроенную реализацию, о которой в Марте 2009-ого было еще неизвестно.
* Mozilla Firefox 3.5+ — июнь, 2009 года
* Microsoft Internet Explorer 8 — 2009 года
* Браузеры, основанные на WebKit (например, Google Chrome, Apple Safari) — я так понимаю, где-то в 2009-году, до июня
* Opera 10.5+
То есть все современные и даже многие устаревшие браузеры имеют встроенную реализацию, о которой в Марте 2009-ого было еще неизвестно.
+2
мне одному кажется что заголовок смахивает на Node.js
0
Sign up to leave a comment.
JavaScript Performance Best Practices