Размеры функций

[melky]

Привет всем. Надеюсь, не стоит спрашивать, зачем строить уровни абстракций и вообще дробить задачи на мелкие подзадачи.

у меня на повестке дня другой вопрос. Все мы знаем, что наш код (JavaScript'овый) сначала компилируется в медленный (относительно) байткод, который при определённой доле статичности компилируется в машинный код (как C++ )

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

Логично же сказать то, что JavaScript'овые движки будут inline'ить функции? Конечно. Но не все.

Мой вопрос связан с тем, какие условия проверяются при том проверке того, можно ли заинлайнить вот эту (сферическую в вакууме функцию в любом вашем коде) функцию?

Среди срача отладочных сообщений V8 мне удалось вытащить некоторые (по любому не все же, верно?) условия, при которых inline'ить функцию нельзя ни в коем случае и следует замедлять её вызов с помощью "полосы препятствий", предложенных спецификацией.

Итак , функцию нельзя inline'ить, если :

• Она проверяет arguments. Вообще, как можно заинлайнить то, что принимает переменное кол-во аргументов?
• Она является встроенной. Сюда относятся и toNumber, NonStringToString из спецификации.
• Она меняет контекст исполнения. Контекст - это this. Пример: функция-callback в setTimeout, setInterval.
• Самое ужасное - в искомой функции слишком много кода.

(пишу по памяти, ибо уже сам давно не прикасался к коду на JS)

И вот последнее мне не даёт покоя. Сколько кода нужно иметь в функции? Каких объёмов они должны быть?

[melky]

Погоди, то есть, если я пишу object.method(), и таких object'ов с общим прототипом (или свойством-функцией) у меня хотя бы две штуки, то эти вызовы обречены пожизненно прозябать в стеке ВМ?
Хочешь сказать, что классы проигрывают процедурщине by design? Что-то не верится. Или я неправильно понял?

второе

если не совру: если при инлайне меняется контекст, то функция не может быть заинлайнена.

ещё она не инлайнится при вызове функции через call\apply.

Много кода там, где много неоднозначностей и абстракций.

Стоило мне отрефакторить функцию, заменив условия и установку значения результирующей переменной на простые return'ы, V8 посчитал, что в ней достаточно кода, чтобы её заинлайнить.
Примеров кода надо найти на просторах винта, так что пока верьте на слово

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

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

тут я сам хз . но можно чуть попоже порыться в сорцах V8


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