Микрооптимизация: возврат из внутреннего блока в конце функции

Question

В таких языках, как javascript или (может быть?) lua, все функции по умолчанию обрабатываются так, как если бы они имели оператор return в конце:

function() {
    // do
    return;
}

равно

function() {
    // do
}

Мне интересно, если возврат из внутреннего блока в конце функции что-то меняет в ядре, процессе компиляции, ВМ.

function() {
    if (condition) {
        return;
    }

    // end of function
}

Тот же вопрос применим на взлом al oop:

function() {
    for ( loop ) {
        return;
    }

    // end of function
}

Машина "ищет" что-нибудь, когда al oop сломан или проверка состояния завершена?

Это не стилист c вопрос, пожалуйста, не говорите мне, чтобы код читался.

Answer 1

TL: DR / совет по оптимизации: вам не нужно делать ничего особенного, чтобы повысить производительность. if(condition) return внутри внутреннего l oop обычно, по крайней мере, так же эффективен, как if(condition)break; для достижения конца функции.

Помещение вложенных циклов внутрь функции, чтобы вы могли использовать return как многоуровневый break - это хороший способ эффективно express логика c без goto, простой для людей и простой для составителей / интерпретаторов.

Создание l oop условия, более сложные, чтобы избежать нескольких return операторов в одной функции, не влияют на производительность.

---

Обычно нет, return в середине функции принципиально не отличается или более или менее эффективный, чем достижение неявного возврата в конце. И явное возвращение в bottom функции также не является особенным.

(Мы говорим о я предполагаю, что void функции, которые никогда не возвращают значение, возвращают значение иначе, чем не возвращают значение.)

Реструктуризация вашего кода до break из всех oop и достижение неявного * 10 24 * в нижней части функции не более эффективна (но может легко быть меньше эффективна в некоторых интерпретируемых языках, особенно если они не являются JIT.), Например, если интерпретатор выполняет переход внутри функции и затем должен сделать еще один прыжок. (Хороший опережающий компилятор или JIT-оптимизатор в любом случае может видеть, что происходит, и создавать хороший машинный код.)

Некоторые компиляторы / интерпретаторы могут обрабатывать return, просто переходя к общему блоку очистки (эпилог), который разделяют все return заявлений. Но возможно дублирование хвоста : при компиляции в машинный код функция может иметь несколько копий инструкций эпилога + ret, доступных с разных путей.

(JavaScript реализации do обычно JIT-функции к машинному коду; IDK примерно LUA. И, конечно, они могут выполнять встроенные функции. return операторы в функциях, которые встроены, могут быть просто переходами или могут быть полностью оптимизированы.)

Answer 2

Я не совсем уверен, правильно ли я понял ваш вопрос, но постараюсь ответить на него с моей точки зрения.

Оператор return в конце объявления функции указывает на выйти из функции и ничего не возвращать ( void ). Если вы пропустите оператор return, ничего не произойдет после фактического выполнения функции. Таким образом, я думаю, что две объявленные вами функции ведут себя по-разному:

function a() {
    // executes until the following statement and then breaks
    return;
}

function b() {
    // executes all statements and afterwards leaves the context where it was called
}

Что касается вашего вопроса, касающегося внутренних блоков, таких как проверки условий или циклы, я думаю, что эти операторы могут быть каким-то образом «оптимизированы» только синтаксическим анализатором если они состоят из значений c, таких как числа или строки. Как только произойдут какие-либо динамические значения c, такие как переменные, будет невозможно что-либо оптимизировать или получить преимущество от внутреннего оператора result.

Надеюсь, вы сможете понять смысл моего объяснения.