Как стать автором
Обновить

Комментарии 10

Memoize с кешем, который ещё и сбрасывать можно, для слабаков.

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

А разумно ли в JS делать мемоизацию через defineProperty? Может, лучше явно получать значение через вызов геттера, чтобы сразу видеть – здесь может быть выполнена какая-то работа.

В конце концов, у нас JavaScript, а не Haskell, тут ожидаешь иного поведения.

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

Как-то немного непривычно. А чем вас не устроили callbackи или Promisы или асинхронные функции?

Они для тяжёлых синхронных вычислений никаким боком. А там, где они применимы, наоборот, не понадобятся заготовки из статьи.

В асинхронщине, кстати, тоже есть свой lazy load, с помощью thenable

Иногда лучше пожертвовать лишним сравнением, но оставить код понятным и читаемым. К тому же, в большинстве языков можно использовать традиционный для таких задач паттерн:
class MyClass {
   #data;
    get data() {
        if (!this.#data) {
           this.#data = someExpensiveComputation();
        }
        return this.#data;
    }
}

Гибрид. Без defineProperty и условных операторов:


class MyClass {
  #data() {
    const result = someExpensiveComputation();
    this.#data = () => result;
    return result;
  }
  get data() {
    return this.#data();
  }
}
В вашем случае есть риски перезаписи поля или получения условного 0 в результате вычислений. Да, можно ещё проверок добавить, но вопрос: а сколько ещё проверок нужно будет добавить?

У автора, конечно, не самый красивый код получился, но можно вынести как утилитарную функцию-обёртку

Глупый вопрос, но если данные изменились и закешированная версия устарела. Как в этом случае быть?

Этот материал — прекрасный примера случая, что происходит когда кто-то начинает заниматься производительностью не производя хотя бы самых элементарных замеров.


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


Одно из первых правил работы, которая предполагает максимальную эффективность кода, это неизменность объекта с момента его объявления. Имеется ввиду его структура, а не данные. То есть такие действия как удаление свойства, добавления свойства, изменения его характера строго противопоказаны.


Подробнее об этом можно увидеть на любой презентации от Google относительно производительности кода для V8 выпускаемых с 2016 года. Уровень сложности таких видео от 10+ а польза значительная.


Рекомендую например
Franziska Hinkelmann: JavaScript engines — how do they even? | JSConf EU
и полезно, и девушка рассказывает что особенно полезно для начинающих бородатых джаваскриптеров.

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