Почему большинство исходных функций JavaScript медленнее, чем их наивные реализации?

Ответ 1

Посмотрев на ECMA-262. Похоже, что собственные реализации просто делают больше с точки зрения обработки ошибок и функций, чем простые самореализации.

Например, проверьте реализацию polyfill map в MDN: Array.prototype.map(). Он основан на том же алгоритме, который указан в ECMA-262. Обновление вашего примера для использования этого алгоритма теперь ускоряет нативную реализацию - хотя и немного: map-native-vs-implemented.

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

Я бы ожидал лучшей производительности для встроенной функции concat. Тем не менее, глядя на ECMA-262, мы видим, что это также делает больше. Рассматривая алгоритм в разделе 15.4.4.4, мы видим, что он обрабатывает некоторые дополнительные случаи. Например, объединение нескольких аргументов - некоторые из них являются массивами, а некоторые - другими типами:

[1, 2, 3].concat([4, 5, 6], "seven", 8, [9, 10]);

возвращает

[1, 2, 3, 4, 5, 6, "seven", 8, 9, 10]

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