Заблуждения в оптимизации

[СлаваRa]

Кость, один нюанс, они практически не принимают помощь, и то что из себя представляет старлинг за время его существования это далеко не совершенство, и гордится там особо нечем.

[Tails]

Сообщение от СлаваRa

Кость, один нюанс, они практически не принимают помощь, и то что из себя представляет старлинг за время его существования это далеко не совершенство, и гордится там особо нечем.

Можно подробнее, в каком смысле не принимают помощь?

[caseyryan]

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

Где-нибудь можно посмотреть на это в работе?

[dimarik]

Двигло даже не в альфе. Могу демку залить, отражающую концепт. В скауте будет видна производительность. Но без сорцов не будет интересно. А сорцы никому не нужны, т.к. даже не в альфе. На самом деле в голове есть пара киллер фич, особенно для мобилок. Вот недавно в голову пришла идея как послойно рендерть item renderers в списках. Они обычно дают нехилую нагрузку в виде множественных drawcalls. Если рендереры похожи между собой и визуально не накладываются друг на друга, то логично их отрисовывать послойно каждый. В свое время, когда работал над мобильным проектом, я пытался изменить способ обхода в списке на by layer. Но оказалось, что построение такого обхода дороже самого рендеринга. Но вот теперь появилась идея как это можно сделать не изменяя стандартного deep-first обхода.

Но все это развивается медленно и печально, на правах хобби.

[СлаваRa]

Было бы очень любезно с твоей стороны рассказать как связаны e4x и ActionScript 3.0 Array и Vector.<T>.

for each...in появился в AS3 именно для работы с xml и его работа полностью соответствует спеке e4x, и для Vector и Array он всегда работает четко, в отличии от for...in.

Но все это развивается медленно и печально, на правах хобби.

так может быть на гитхаб запилить?

[caseyryan]

for each...in появился в AS3 именно для работы с xml и его работа полностью соответствует спеке e4x, и для Vector и Array он всегда работает четко, в отличии от for...in.

Слав, в доках этого нет. Так что зря ты это затеял)
Если бы там было написано, что для вектора и массива порядок обхода всегда гарантированно строгий, то не вопрос. А так, сделать что-то, где важен порядок на for each in, а потом искать гейзенбаги, как-то не камильфо.

Но все это развивается медленно и печально, на правах хобби.

так может быть на гитхаб запилить?

Поддерживаю. А почему нет? Кинуть клич, так сказать. Если рендер там получится лучше, чем в старлинге, то, уверен, спросом пользоваться будет

[СлаваRa]

Слав, в доках этого нет. Так что зря ты это затеял)

есть а спеке e4x

[caseyryan]

есть а спеке e4x

Где конкретно там говорится об as3 массивах и векторах?

[alatar]

Что-то тут уже теплое с мягким начали сравнивать. При использовании for each будет генерироваться одинаковый код, что для объекта, что для массива. А вот в каком порядке будут обходиться значения, зависит только от объекта (т.е. что hasnext2 (байткод) вернет, так и пойдем). В некоторых случаях и для обычного объекта можно добиться повторяемости обхода значений.
P.S. По поводу того, что for компилируется в while — это не совсем так, в байткоде нет ни того ни другого.

Добавлено через 51 минуту
P.P.S. Кстати, метод forEach массива и вектора, внутри использует for для обхода элементов.

[dimarik]

Ну так на чем остановились-то? Пользуем for [each] in для обхода Array и Vector.<T> или от греха подальше?

Я, по-старинке, всегда уточняю размер коллекции в константу или переменную и вперед.

const len:uint = collection.length;
for (var i:uint = 0; i < len; i++) {
    collection[i];
}