LINUX.ORG.RU

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

 , ,


0

2

нода (v8), парсер yaml. Оптимизируется скорость.

Интересует, насколько есть смысл (с точки зрения скорости) все фигачить в одну километровую функцию, вместо вызова мелких. Есть подозрение, что создание объектов (из yaml) все равно похерит профит. А тогда нет смысла черезмерно уродовать код (даже если использовать макросы на sweet.js).

Кто-нибудь занимался хардкорной оптимизацией JS? Например, для монги и редиса пишут прямым текстом, что драйверы доточены до такого состояния, что не уступают нативным (на сях). Хочу для ямла добиться таких же понтов.

★★★★★

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

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

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

special-k ★★★ ()
Ответ на: комментарий от special-k

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

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

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

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

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

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

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

special-k ★★★ ()
Последнее исправление: special-k (всего исправлений: 3)
Ответ на: комментарий от Vit

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

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

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

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

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

Vit ★★★★★ ()
Ответ на: комментарий от trashymichael

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

special-k ★★★ ()
Последнее исправление: special-k (всего исправлений: 1)

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

maloi ★★★★★ ()
Ответ на: комментарий от Vit

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

trashymichael ★★★ ()
Ответ на: комментарий от special-k

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)

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

Vit ★★★★★ ()

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

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

Boba_Fett ()
Ответ на: комментарий от Vit

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

trashymichael ★★★ ()
Ответ на: комментарий от trashymichael

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

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

Vit ★★★★★ ()
Ответ на: комментарий от special-k

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

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

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

Vit ★★★★★ ()
Ответ на: комментарий от Vit

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

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

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

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

special-k ★★★ ()
Ответ на: комментарий от special-k

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

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

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

Vit ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.