Указанная вами документация является неточной для текущих реализаций WebAssembly. Только у Chakra есть интерпретатор, и любая «горячая» функция JIT-компилируется независимо от ее размера. Реализация JavaScript в JavaScript WebAssembly только для JIT-компиляций, а «горячие» функции перекомпилируются на более высоком уровне оптимизации.
Как говорится, выделение имеет несколько преимуществ:
- Двоичный файл
.wasm может стать меньше. Это означает, что он загружается быстрее.
- Теоретически, движки могли бы повторно встроить небольшие выделенные функции, если бы мы часто видели их в Интернете, поэтому вы не получите потери производительности при выделении.
- Большие функции иногда занимают больше времени для JIT-компиляции, часто компиляция нелинейная (хотя, опять же, движки меняются со временем и могут лучше обрабатывать большие функции, если это станет распространенной проблемой).
- Механизмы часто компилируются параллельно на границе каждой функции, поэтому более мелкие функции лучше компилируются параллельно и больше заполняют конвейер компиляции (особенно ближе к концу компиляции, если у вас осталось всего несколько больших функций для компиляции ядра не будут использованы). Это довольно незначительный момент, я бы об этом не беспокоился.
Однако все это постоянно меняется, разработчики движков реагируют на то, что мы видим в Интернете, и настраиваем движок для лучшей обработки реального кода. Часто хорошо делать то, что правильно, и регистрировать ошибки на каждом движке, если вы видите патологии. Здесь это может означать уменьшение размера загрузки с помощью выделения контуров и ожидание хорошего повторного наложения.