Есть ли смысл разворачивать вызовы функций?

Вызов функций занимает время, но небольшое. На сколько небольшое - проведи эксперимент. Но 10-20 функций погоды не сделают точно, особенно в сравнении с регулярными выражениями и длинными циклами. Возможно из циклов стоит убрать вызов функций.

Но там еще много других моментов http://www.youtube.com/watch?v=tCG0aPNvkTs

А так же, не слышал чтобы кто-то говорил, но такая очевидная вещь как инициализация объектов, тоже должна использоваться по-минимому. Самый простой косяк который с этим может быть, писать внутри функции или цикла «какой нибудь стринг», то бишь инициализировать его каждый вызов или итерацию.

Речь конечно же о вызовах функций внутри циклa.

Второй момент, с которым я сталкивался - немеряно долгое создание сложных объектов. Из монги когда тупым нативным запросом фетчился развесистый хеш, это было в несколько раз дольше, чем когда поля выборки ограничивались. Хотя казалось бы, там, там блоб всосать и десериализовать.

За ссылку спасибо. Дельное видео. Есть еще аналогичные же или сложнее?

Речь конечно же о вызовах функций внутри циклa.

Суть та же, если время выполнения итерации гораздо больше чем вызов функции, то можно.

немеряно долгое создание сложных объектов

Очень похоже, как раз, на деоптимизацию. Т.е. интерпретатор не может предположить класс объекта, определить закономерность в его структуре, и как следствие, создает медленно. Проще все должно быть (ну и те моменты, что были подчеркнуты, как дыры в массивах, NaN, разные типы и т.п.) возможно вытаскивается структура крайне неудобная для js.

Есть еще аналогичные же или сложнее?

например это (только для spidermonkey) http://blog.mozilla.org/javascript/2012/10/15/the-ins-and-outs-of-invalidation/

Но, помоему все можно выразить фразой: «одинаковое лучше чем разное».

со времен просиживания штанов на геймдев.ру форуме, считаю что вызов функции ничего не стоит. это утрированно конечно, но как ни крути

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

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

В парсере ямла имеет значение только скорость. Примите это как данность. Не хотелось бы скатываться в ЖЖ.

js достаточно производительная платформа, чтобы гнаться за скоростью.. это не пых) Но верно то, что про поддерживаемость кода так же нельзя забывать.

не знаю как там в v8, но нормальный jit небольшую часто вызываемую функцию (в цикле, например) заинлайнит, и времени на вызов тратится будет ровно 0.

и что есть задачи когда парсить надо в цикле и этот код требователен к производительности?

https://github.com/dervus/js-yaml-benchmark

Ничо так ускорилось...

Sample: application.yml (2055 characters)
 > JS-YAML (old)         x 370 ops/sec ±1.98% (88 runs sampled)
 > YAML.js               x 1,238 ops/sec ±0.65% (96 runs sampled)
 > JS-YAML (new, safe)  : 
 > JS-YAML (new, unsafe) x 11,687 ops/sec ±0.94% (97 runs sampled)


Sample: application_big.yml (223996 characters)
 > JS-YAML (old)         x 1.75 ops/sec ±1.79% (8 runs sampled)
 > YAML.js               x 12.22 ops/sec ±2.07% (34 runs sampled)
 > JS-YAML (new, safe)  : 
 > JS-YAML (new, unsafe) x 125 ops/sec ±0.37% (81 runs sampled)

Надо конечно еще много чистить, но в целом радует.

насколько есть смысл (с точки зрения скорости) все фигачить в одну километровую функцию

Которая в итоге не поместится в кэш. Ферштейн?

еще хотелось бы в целом продолжить полемику про необходимость всех этих ямлов и их парсеров, чем жсон-то не устроил?

Так исторически сложилось. Я только недавно узнал, что такое джисон, но отказываться от ямла уже поздно.

Там в 50 раз ускорение конечно не из-за оптимизаций жабаскрипта, а из-за полной переделки архитектуры.

Оптимизации втыкать было некуда - при внимательном изучении оказалось, что почти все учтено, как ни странно. Мелкие твики эффекта не дали.

Еще про оптимизацию http://floitsch.blogspot.ru/

Спасибо. Позырил, там хардкор совсем.

IMHO, если человек всерьез собрался активно дебажить код на таком низком уровне - наверное он выбрал не тот язык :) . Инструменты мягко говоря не фонтан.

Проще контролировать полиморфизм в процессе написания.

наверное он выбрал не тот язык

А в браузере есть другой язык?)

Проще контролировать полиморфизм в процессе написания.

Не знаю что проще, у меня уже скоро паранойя начнется :)

В браузере вообще пофик - это проблемы клиента, что у него мобилка за час сядет :)

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

Эксперименты с ямлом были just for lulz. С точки зрения бизнеса, когда надо за указанные бабки и время получить гарантированный результат, я б в такие подвиги не вписался.