Добавив в
benchmark,
в качестве которого служит сам транслятор, исполнение версий на Java и JavaScript, обнаружил, что
для последнего при включённых проверках индексов массивов происходит ~ 8-кратный перерасход памяти по
сравнению с выключенными
проверками, что было незаметно на небольших программах. Расход памяти, в свою очередь, приводит и к ощутимо
большему времени исполнения, чего, опять-таки, не было в простых тестах.
Перерасход был вызван, в основном, тем, что методы доступа к элементам массива находились в самом массиве,
что было сделано в расчёте на потенциально высокую возможность оптимизации при JIT-исполнении и без учёта влияния
на занимаемую память. Замеры показали всё, как есть - и неоправдавшиеся надежды на оптимизации, и ужасы
накладных расходов на сборку мусора.
Оптимальным по всем параметрам
решением
оказалось добавление методов доступа непосредственно классу Array
вместо создания дополнительных обёрток.
Дополнительно в JavaScript была устранена генерация проверок индекса для простых случаев, когда статически
известно о гарантиях корректного обращения к массиву. Также, была усовершенствована пометка переменных, которые
участвуют в вызовах подпрограмм в качестве VAR-параметров, что в Java и JavaScript имитируется через массивы.
Это позволило устранить превращение в массивы переменных в вызовах NEW, PACK, UNPK.
