FF пишет о том, что asmjs код скомпилирован за такое-то время, этого достаточно чтобы понять, что директива где-то есть и не искать ее в дебрях скомпилированного кода. Я думаю, что вы скорее ее где-то потеряли так как ее принудительное отключение попросту не имеет смысла.
Публичные версии юнити пока не умеют компилировать в WebAssambly (есть демо angry bots, но оно сделано внутри компании).
Оказывается можно и без класса. Супер будет работать для методов с [[HomeObject]]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/super
https://learn.javascript.ru/es-object
В js в браузере нет интерпретатора, есть разные виды компиляторов. Наличие директивы «use asm» никак не влияет на отладку. При открытом отладчике FF иногда отключает AOT компиляцию, но на отладку это не влияет. Я проверил ради интереса — в обоих случаях работает AOT компиляция, так что все осмыслено и директива остается на месте.
Давайте называть вещи своими именами. WebAsembly — это на данный момент бинарное представление asmjs. Asmjs — подмножество js. Даже при выключенной AOT компиляции данный код не перестает оптимизироваться лучше так как содержит только арифметику и работу с кучей и не содержит объектов и собственно не перестает быть asmjs кодом.
На счет директивы — вы думаете ее специально отключают? С какой целью? Это ведь одна строчка в коде выставляемая emscripten которая вряд-ли экономит время сборки. Сейчас тоже проверю на чем-то простеньком.
Да проблем хоть отбавляй! Одно могу сказать со времен 5.0бета все стало горааааздо лучше. Билды собираются более стабильно (раньше валились раз через раз), уменьшилось потребление памяти, увеличилась производительнось, починили шейдеры и тени.
А проблемы вот на вскидку: Пока не работает антиалиасинг. Проблемы с работой IndexedDB в сафари при использовании LoadaFromCacheOrDownload (лечится кастомным js лоадером). Проблемы с переходом в полноэкранный режим по нажатию кнопки в гуи — в разных браузерах не всегда отрабатывает маусап (тут пока вылечил жутким костылем с проверкой фулскрина на апдейт). Проблемы с переходом в фулскрин в опере (часть экрана обрезается). Для звуков нужно принудительно отключать эффект Доплера. В ИЕ билд валится из за отсутсвия поддержки аудио апи (раньше валился только при обращении к звуковой системе). И такого еще полно.
function testFunction(...args) {
const l = args.length;
var a = new Array(l);
for(let i = 0; i < l; i++) a[i] = args[i];
return a;
}
C use strict arguments это тоже просто объект. Проблемы с внутренней кухней оптимизации не предсказуемы. Я думаю как только будет оптимизироваться ...args будет оптимизироваться и Array.form (механизм работы у них схожий), хотя опять же, это все очень не предсказуемо.
Общий вывод поддерживаю — есть смысл пользоваться es6 с бабелем или без, а там где нужна оптимизация переходить к старому доброму for или уже переходить на asmjs и/или glsl (зависит от задач).
Итого проверил в node 5.10.1 и chrome 49.0.2623.112 со включенным use strict:
function(...args) {var a = args; return a;} // не оптимизируется
function() {var a = Array.from(arguments); return a;} // не оптимизируется
function() {var a = []; for(let el of arguments) a.push(el); return a;} // оптимизируется TurboFan
function() {var a = []; for(var i = 0, l = arguments.length; i < l; i++) a.push(arguments[i]); return a;} // оптимизируется
function() {var a = Array.prototype.concat.apply(Array.prototype, arguments); return a;} // оптимизируется
Итого оптимизация случается крайне редко, ES6 пока оптимизируется плохо или не оптимизируется.
Так получается, что критически важные по скорости задачи все равно пишутся с использованием классического for, а в остальном нет смысла отказываться от удобных и читаемых конструкций будь то ...args, Array.from или for of.
Нет, я исходил из соображений, что утечка отсутсвует и потому оптимизация должна быть. Теперь обязательно проверю. Тем более интересен тот момент, что Array.from не может менять arguments, так что это не совсем обычная функция.
Статье уже год как, думаю это стоит проверить тем более Array.from как раз создан для работы с итерируемыми объектами и от ...args не слишком то отличается.
Публичные версии юнити пока не умеют компилировать в WebAssambly (есть демо angry bots, но оно сделано внутри компании).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/super
https://learn.javascript.ru/es-object
На счет директивы — вы думаете ее специально отключают? С какой целью? Это ведь одна строчка в коде выставляемая emscripten которая вряд-ли экономит время сборки. Сейчас тоже проверю на чем-то простеньком.
А проблемы вот на вскидку: Пока не работает антиалиасинг. Проблемы с работой IndexedDB в сафари при использовании LoadaFromCacheOrDownload (лечится кастомным js лоадером). Проблемы с переходом в полноэкранный режим по нажатию кнопки в гуи — в разных браузерах не всегда отрабатывает маусап (тут пока вылечил жутким костылем с проверкой фулскрина на апдейт). Проблемы с переходом в фулскрин в опере (часть экрана обрезается). Для звуков нужно принудительно отключать эффект Доплера. В ИЕ билд валится из за отсутсвия поддержки аудио апи (раньше валился только при обращении к звуковой системе). И такого еще полно.
C use strict arguments это тоже просто объект. Проблемы с внутренней кухней оптимизации не предсказуемы. Я думаю как только будет оптимизироваться ...args будет оптимизироваться и Array.form (механизм работы у них схожий), хотя опять же, это все очень не предсказуемо.
Общий вывод поддерживаю — есть смысл пользоваться es6 с бабелем или без, а там где нужна оптимизация переходить к старому доброму for или уже переходить на asmjs и/или glsl (зависит от задач).
Итого оптимизация случается крайне редко, ES6 пока оптимизируется плохо или не оптимизируется.
Так получается, что критически важные по скорости задачи все равно пишутся с использованием классического for, а в остальном нет смысла отказываться от удобных и читаемых конструкций будь то ...args, Array.from или for of.