Привязка данных в Dart вдохновлена MDV (Model Driven Views), который действительно не является частью вебкомпонентов. Однако, части необходимые для MDV постепенно проникают в платформу:
скрытые классы всегда используются. словарное представление тоже имеет скрытый класс, который собственно и говорит что поля представлены словарем.
превратится-ли result в словарь зависит от количества полей и некоторых других факторов.
основное ускорение здесь получается от того, что вы полустатическим образом фиксируете структуру литерала в коде, не нужно ничего растить и т.д., то, что он не перейдет в словарь дополнительная плюшка из этого.
ну и eval'а на V8 нужно избегать как огня — произведенный им код не оптимизируется. хотя в данном конкретном случае это и не важно, потому что основное время тратится в клонировании object literal boilerplate, которое выполняется большей частью в стабе.
ничто не мешает, просто не реализованна нормальная протяжка констант. а без протяжки констант на одном локальном type feedback тут далеко не уедешь из-за полиморфизма точки вызова внутри цикла, который внутри forEach.
над каждым элементом функция честно вызывается. в зависимости от того, что функция делает цена этого вызова может быть заметна, а может быть амортизированна и не очень заметна.
если vector существует в единственном числе, то тут разницы между глобальным и не глобальным scope не должно быть.
Хранение 32-битных величин сложный вопрос. На ia32 те из них которые не влезают в smi (31-bit signed integer) превратятся в полновесные числа с плавающей точкой. Зависит от многих факторов: как много тех кто не влезает в 31бит, как они будут использоваться и т.д. Int32Array может оказаться оптимальным в некоторых случаях.
дырки это та проблема, которой рекомендации рекомендуют избегать, чтение из дырки требует поиска свойства через цепочку прототипов и оптимизированный код не любит этого и просто деоптимизируется. К тому же если у вас в массиве много дырок, то V8 может внезапно решить, что память важнее производительности и ради экономии места превратит длинный дырявый массив в словарь.
splice же, который удаляет и сдвигает элементы не оставляет после себя дырок, поэтому безобиден в данном отношении. Следует, впрочем, всегда помнить, что он имеет линейную сложность по количеству сдвигаемых элементов.
64-битная сборка только на Linux используется AFAIK
> Но у вас в блоге заметил странную магию с «use strict», который не дает захватывать контекст.
В данном конкретном примере "use strict" разрывает связь между arguments и формальными параметрами. Это убирает создание контекста и позволяет инлайнить этот код (если функция создает контекст, то такую пока V8 не инлайнит).
я бы сказал, что это спорная рекомендация и они совсем не эквивалентны. все конечно же зависит от конкретного кода, splice, например, линейная операция по количеству сдвигаемых элементов. в каких-то случаях может лучше arr[i] = null; делать (хоть оно и не эквивалентно delete)
1. По типу содержимого быстрые элементы бывают трех видов и трансформируются в одном направлении от менее общих к более общим: smi (small integer) -> double -> object. Бывают еще дырявые (holey) и непрерывные (packed). Еще бывают медленные элементы — представляются словарем.
2. Рекомендация соблюдать мономорфизм относится не к функциям, а к отдельным операциям, например, оператору умножения, оператору [] или вызову метода. Операции работают быстрее, когда они мономорфны — выполнятся над объектами одного и того же типа/скрытого класса. Как вы определяете «полиморфную функцию»?
3. V8 инлайнит функции, которые требуют переключения контекста на ia32 (Mac, Windows), но не инлайнит на x64/arm. Что касается функционального программирования, то зависит от того какие именно паттерны мы сравниваем. В большинстве случаев ООП основанное на связке constructor + prototype chain имеет больше шансов быть хорошо заоптимизированным. Можно почитать мой блог о том, какие именно проблемы возникают если опираться на замыкания: mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html
А собственно кроме узких мест ничего никогда тюнить и не надо. Все советы по оптимизации бесполезны в 99% случаев, пока вы не наткнетесь на случай попадающий в злые 1%, где надо костьми лечь но выжать все что можно.
у arguments object достаточно мутная семантика, поэтому если v8 видит, что он используется нетривиальным образом, то она отказывается оптимизировать. это проистекает из соображения, что в коде, для которого важны оптимизации, arguments чаще всего не используется или используется тривиальным способом, поэтому и реализовывать сложную поддержку нет смысла. (меньше сложностей — меньше багов).
какой факт? что замеры производительности С++ кода на разных машинах, компиляторах и флагах сборки дали разные результаты? это действительно факт.
обратите внимание, я не пытаюсь утверждать, что V8 производит в данном конкретном случае супер код (хотя я посмотрел на него и код достаточно хороший, если не считать бага описнного внизу) или что пересечение границы JS-C++ легче перышка. я утверждаю другое: разница в десятки миллисекунд на таком коде не может быть объяснена задержками при пересечении этой границы.
более того, я даже склоняюсь ко мнению, что у автора что-то со флагами компиляции не так — из-за чего скорость С++ного кода оказалась такой странной. но для подтверждения надо посмотреть на то, что его компилятор породил в этом месте. (еще заметьте, что и время исполнения обычного С++ного варианта и CUDA-вского включают в себя время пересечения границы JS-C++, т.е. оно меньше 17ms).
какой факт? что замеры производительности С++ кода на разных машинах, компиляторах и флагах сборки дали разные результаты? это действительно факт.
обратите внимание, я не пытаюсь утверждать, что V8 производит в данном конкретном случае супер код (хотя я посмотрел на него и код достаточно хороший, если не считать бага описнного внизу) или что пересечение границы JS-C++ легче перышка. я утверждаю другое: разница в десятки миллисекунд на таком коде не может быть объяснена задержками при пересечении этой границы.
более того, я даже склоняюсь ко мнению, что у автора что-то со флагами компиляции не так — из-за чего скорость С++ного кода оказалась такой странной. но для подтверждения надо посмотреть на то, что его компилятор породил в этом месте. (еще заметьте, что и время исполнения обычного С++ного варианта и CUDA-вского включают в себя время пересечения границы JS-C++, т.е. оно меньше 17ms).
у меня на ноде v0.8.8 вылазит баг в V8ом выводе представлений (representation inference) из-за которого замена на стэке (on stack replacement) пораждает совершенно бредовый код, в котором он пытается привести заведомо не целое значение к целому из-за чего происходит деоптимизация… в результате код постоянно крутится в неоптимизированной версии.
если же я запрещаю OSR и вызываю integrateJS дважды, то картина с пиковой производительностью получается примерно такая:
omega ~/src/temp/perl_vs_node ∳ git diff [master@368da]
diff --git a/integral.js b/integral.js
index 7b11f22..194adb2 100755
--- a/integral.js
+++ b/integral.js
@@ -18,4 +18,5 @@ function integrateJS(x0,xN,y0,yN,iterations){
console.log("JS time = "+(new Date().getTime() - time));
}
-integrateJS(-4,4,-4,4,1024);
\ No newline at end of file
+integrateJS(-4,4,-4,4,1024);
+integrateJS(-4,4,-4,4,1024);
omega ~/src/temp/perl_vs_node ∳ node integral.js [master@368da]
JS result = 127.99999736028109
JS time = 132
JS result = 127.99999736028109
JS time = 115
omega ~/src/temp/perl_vs_node ∳ node --nouse-osr integral.js [master@368da]
JS result = 127.99999736028109
JS time = 122
JS result = 127.99999736028109
JS time = 55
баг я зарапортую на эту тему. причина по моей прикидке в том, что начальное значение переменной result — 0 выглядит как целое число и попадая в phi-функцию на границе между нормальным потоком управления и OSR-entry блоком приводит к неправильному выводу представления для этой phi (https://github.com/v8/v8/blob/d3924c236bfca217385eaf5355a96146f0dcc60d/src/hydrogen-instructions.cc#L2567-2576 < — код увидев 0 выберет целое представление) и почему-то посказки (hint) для HUnknownOSRValue на обратной дуге не сработали.
Кстати, если заменить result = 0, на result = 0.1 баг в representation inference по понятным причинам пропадает.
функция вызывается один раз и выполняется сотни миллисекунд. в таком случае накладные расходы на пересечение границы просто незаметны. они ведь отнюдь не десятками миллисекунд измеряются, а совсем даже долями миллисекунды.
утечка — это когда память болтается непонятно где, не используется и не может быть переиспользована. а здесь не эффективное использование памяти, потому что это память никуда не пропала и занята объектом, на который есть валидные ссылки из другого объекта.
а сами объекты с 9 свойствами, конечно же, помирают… просто они были меньше с словаря, который теперь свисает с каждого testedObject[i], что пораждает иллюзию их живости.
Прежде всего совет: не пытайтесь понять, что удаляется, а что не удаляется по графику потребления памяти — это гадание на кофейной гуще. Просто посмотрите на снапшот кучи.
Объяснение (по крайней мере для Хрома) очень простое: когда вы делаете delete testedObject[i].obj, V8 нормализует объект testedObject[i] — трансформирует его из быстрого компактного представления в медленное и раздутое представление на основе словаря, который еще и выделяется с запасом по размеру. При этом V8 не замечает, что после удаления в словаре будет пусто — и словарь (800 байтов) остается болтаться в воздухе. И так для каждого из ваших объектов.
это не совсем правильный вывод: бенчмарк фокусируется на производительности чистого javascript, который однопоточен по своей природе. (workerы не являются частью ECMAScript стандарта и потому в тестах не используются). поэтому основной поток исполнения бенчмарка просто не может загрузить больше одного ядра.
некоторые JavaScript рантаймы, впрочем, испольуют потоки для различных внутренних целей: например, конкурентная сборка мусора и компиляция в Chakra, параллельная фаза разметки (marking) в JavaScriptCore, фаза sweeping в SpiderMonkey. так что наличие нескольких дополнительных ядер только на пользу.
Тесты в V8 Benchmark Suite могут со стороны выглядеть совершенно случайными, но на самом деле они тестируют фундаментальные вещи. NavierStokes, например, тестирует качество оптимизаций операций над числами с плавающей точкой и скорость работы массивов содержащих числа с плавающей точкой.
Проблема с большим реальным кодом состоит в том, что в нем сразу множество факторов влияющих на производительность смешиваются, поэтому V8 Benchmark Suite пытался разложить, так сказать, различные факторы по полочкам и каждый бенчмарк был достаточно сфокусирован на фичах языка, которые V8 хотела ускорить: DeltaBlue — полиморфный объектно-ориентированный код, Crypto — побитовые операции и т.д.