Просмотр полной версии : Внутренняя задержка генерации объектов: P166=P2400 xi.net.ru/drawboard.php?npage=1
Вот возник такой вопрос: кто-нибудь замечал, что в Flash зачем-то введена задержка генерации объектов?
Возмем простой пример - создадим ролик с пятью-десятью кадрами. В корне создадим объект с именем "cpb". В каждом кадре напишем такую вещь
t1=gettimer();
for (x=1;x<=100;x++) {
duplicateMovieClip (_root.cpb, "p"+npix, i);
setProperty ("p"+npix, _xscale,x);
setProperty ("p"+npix, _yscale,x);
npix++;
}
t2=gettimer();
dt=(t2-t1)+dt;
В первом кадре в самом начале добавим строки
npix=1;
dt=0;
А в последнем кадре выведем значение dt на экран.
Что делает этот скрипт? Просто замеряет время, которое уходит на создание большого числа копий (дупликатов) объекта и на задание ему некоторых свойств. Время переключения между кадрами сюда не входит.
Теперь запустим этот ролик на слабой машине в стиле P-166КГц и на мощном компьютере P4-2,4ГГц.
Что увидим?
Замеренное время практически совпадает!!
И оно довольно велико. То есть как бы вы не старались, получить приличную скорость генерации или изменения свойств объектов не получится. А это значит, что в флеш-проигрывателе есть какя-то задержка, причем скорее всего синхронизированная с таймером.
Пример можно посмотреть на http://xi.net.ru/drawboard.php?npage=1 Залитие при начальной инициализации листа белым фоном примерно ~0,3 секунды на горизонтальную линию (генерация 64-х объектов "квадратик"). Та же задержка и если просто поменять свойства у нескольких объектов (нажимаем пиктограмки уменьшить/увеличить)
Вопрос! Как обойти это ограничение? Может есть какая недокументированная переменная, или функция, которая регулирует или отключает эту задержку. Или можно еще как-нибудь ускорить ролик?
Nox Noctis
21.05.2004, 12:42
Оригинал написал(а) xintrea
Время переключения между кадрами сюда не входит.
....
....
Замеренное время практически совпадает!!
....
как бы вы не старались, получить приличную скорость генерации или изменения свойств объектов не получится
....
....
Может есть какая недокументированная переменная, или функция, которая регулирует или отключает эту задержку.вы, иван, кажется пивовар? :))
вопрос вызван, скорее всего, незнанием материала :)
программирование во флэше - это отдельная тема, и тут дело вовсе не в языке на основе ецма262, а в том что ориентирован флэш изначально на показ анимации. простой анимации, интерактивной анимации, любой другой анимации - это прежде всего. и ключевые слова тут - frame rate. частота кадров в секунду.
всё в основном подчиняется фреймрейту.
код, кодторый ты пишешь в кадрах, срабатывает в момент перехода по этим кадрам. а скорость перехода по кадрам - это фрейм рейт. выполнение кода в кадрах может занимать время большее, чем отведено на эдин кадр - тогда фрейм рейт будет падать, но флэш плеер автоматически старается приблизить скорость смены кадров к номинальной.
что делаешь ты - по сути дела ы замеряешь время между началом и окончанием линейки кадров. и удивляешься что оно почти одинаково на разных машинах...
...так это же офигенно здорово :)))
представь что было бы, если бы частота кадров напрямую зависела от мощности машины. (нуу... впрочем, она и зависит канеш - но косвенно.)
если хочешь замерить скорость выполнения кода на разных машинах - то тебе нужно замерить в каждом из кадров время выполнения кода, потом вывести среднее арифметическое этих значений, и посмотреть что получится. поставь несколько тысяч повторений этого цикла, и проверь так. увидишь разницу... (но тестить надо в максимально удентичных условиях - одинаковые операционки, одинаковые версии плееров\плагинов, одинаковые версии браузеров)
Оригинал написал(а) Nox Noctis
вы, иван, кажется пивовар? :))
вопрос вызван, скорее всего, незнанием материала :)
Скорее всего наоборот. Копаю глубоко.
программирование во флэше - это отдельная тема, и тут дело вовсе не в языке на основе ецма262, а в том что ориентирован флэш изначально на показ анимации. простой анимации, интерактивной анимации, любой другой анимации - это прежде всего. и ключевые слова тут - frame rate. частота кадров в секунду.
всё в основном подчиняется фреймрейту.
Согласен, но в этом эксперименте фрейм рейт и рядом не лежит.
код, кодторый ты пишешь в кадрах, срабатывает в момент перехода по этим кадрам.
???
Внимательно смотрим на код. В коде замеряется дельта времени между началом и концом КРУЧЕНИЯ ЦИКЛА. Для нескольких кадров эти дельты складываются. Получаем время, потраченное только на кручение цикла во всех кадрах.
Для большего понимания, посмотри что накопали буржуи.
http://www.flash-ripper.com/archives/000148.htm
что делаешь ты - по сути дела ы замеряешь время между началом и окончанием линейки кадров. и удивляешься что оно почти одинаково на разных машинах...
Садитесь, иванов, два! Я замеряю время В ПРЕДЕЛАХ ОДНОГО КАДРА. И складываю это время, замеренное у разных кадров для большей статистики. Линейка кадров здесь - просто для того, чтоб эту статистику и наработать.
... Бред скипнут ...
В ролике http://xi.net.ru/drawboard.php?npage=1 фрейм-рейт установлен на 100 кадров/сек. Появление одной линии - это прощелкивание одного кадра, и время тратится ~0,3 сек. То есть времени на создание кадра уходит больше чем времени, расчитанному по фрейм рейту, ну да пофигу, не в этом дело.
Открываешь этот ролик на P-166, видишь ~0,3 сек делается один кадр.
Открываешь этот ролик на P-2,4ГГц, тоже видишь ~0,3 сек делается один кадр.
Фрейм-рейт тут вообще не причем, если бы по нему считалось, кадры бы прощелкивались за 0,01 сек, ActionScript прерывался б на середине, и пропускались кадры с ActionScript-вставками.
Вопрос остается открытым - как ускорить ролик, поменять системные константы флеш-плейера или еще что. Жду ответа профессионалов.
1) Прикладываю файл. Пример явно показывает, что даже в пределах одного мувика одни и те же действия выполняются разное время, не говоря уж о разных машинах.
2) у буржуев чайников не меньше чем у нас, и имя "Питер Холл" без ссылки на первоисточник мне лично ни о чем не говорит. (старая сказка "а вот в развитых странах...")
3) почитай спецификации формата SWF - они открыто лежат на сайте Macromedia,
вот ссылка ( [http://download.macromedia.com/pub/flash/flash_file_format_specification.pdf)
4) Если уж Nox для тебя не авторитет, то кто же? Может John'a сюда позвать?
ЗЫ. Накопали не буржуи, а риперовцы, а это всё-таки разные вещи. Не люблю я буржуев. И когда меня скипают не люблю.
ЗЗЫ Попробуй погонять мой пример с разной загрузкой проца - наглядный показатель :)
вот - картинка:
http://dindin.boom.ru/sample.gif
http://dindin.boom.ru/sample.gif
Для большего понимания, посмотри что накопали буржуи.
http://www.flash-ripper.com/archives/000148.htm
зачем-то решил проверить, получилось с точностью до наоборот:
a = [];
t = getTimer();
for(var i=0; i<100000; i++){
a[i] = 1;//1391 (для шестерки); 1295 (для семерки)
//a.push(1);//1661 ;1521
}
trace(getTimer()-t);
непонятка, однако..
Nox Noctis
23.05.2004, 18:55
не надо грязи :)
вместо того чтобы защищать своё самолюбие почитай, пожалуйста, то что я написал выше :) м? особенно скипнутый бред.
особо радует вот это высказывание
Согласен, но в этом эксперименте фрейм рейт и рядом не лежит
и вот это хит:
Фрейм-рейт тут вообще не причем, если бы по нему считалось, кадры бы прощелкивались за 0,01 сек, ActionScript прерывался б на середине, и пропускались кадры с ActionScript-вставками.тут нужно мнение не профессионалов, а психотерапевта.
насчет буржуев - очень жаль, но в той статье написано вообще о другом :) там говорится примерно о том же, о чем есть упоминания в доке по flasm'у - рассказывается о разницах синтаксиса, и чем вызваны различия их работы.
про незнание материала я сказал по двум причинам:
1. потому, что ОСНОВНАЯ специфика флэшовых программ - привязка ВСЕХ действий к фремрейту. (даже действия заданые при помощи setInterval c промежутком времени меньшим чем длительность одного кадра)
2. создание клипов не подходит для бенчмарка вообще. что ты хотел проверить? производительность плагина? тогда взял бы какие-нить математические функции. производительность видяхи очень сильно влияет на скорость работы плеера. и память тоже - тем более что ты выбрал вариент для тестов, в котором необходимо каждый кадр перерисовывать сцену с тысячей объектов. с частотой 100фпс, ага :))
и не надо эти вещи воспринимать как личное оскорбление. ты просил обсудить то что у тебя получилось - я обсуждаю.
пример чистого бенчмарка (тот самый вариант, который "раскопали" "буржуи". (к слову - это было больше двух лет назад :)) :
_global.total = 0;
_global.count = 0;
this.onEnterFrame = function() {
_global.count++;
var s = getTimer();
for (var x = 0; x<2000; x++) {
Math.asin(Math.sin(1/Math.sqrt(1+random(100))));
}
var e = getTimer();
_global.total += e-s;
};
this.onMouseDown = function() {
trace("average : "+total/count+"ms");
};
кроме этого в ролике не должно быть ничего. всего один кадр с этим кодом.
получаем (опять таки - ПРИ ПРОЧИХ РАВНЫХ производительность плагина для данной конфигурации системы) возможно, потребуется сменьшить количество итераций или фреймрейт (дадада :) ), чтобы не выпадала ошибка плеера.
зы: бригада профессионалов уже в пути :))
чего -то бум глюкует сёдня. Вот пиктуре.
Nox Noctis
23.05.2004, 18:59
Оригинал написал(а) silin
непонятка, однако.. это было два года назад :)
рост это написал почти полтора года назад, а эта тема появилась года два как.
ты небось проверяешь в седьмом плеере? (даже если паблишишь под шестёрку - всё равно плеер переделан уже)
Ой, задел ты меня, дорогой товарищ xintrea, за живое своим скипом. Этот твой скип - он теперь мне вроде шила в одном месте - сидеть спокойно не дает...
Итак. Ни для кого, надеюсь не секрет, что флэш построен на принципе виртуальной машины. Самый близкий аналог, пожалуй Java. И флэш-плеер является для него ни чем иным, как интерпретатором. То есть той самой VM.
Аналогии с Явой очень близкие. Вплоть до того, что в AS2.0 принцип обработки исключений почти полностью позаимствован из JVM. Поэтому в дальнейшем я буду ссылаться на Java Virtual Mashine в целом (хотя это несколько различных машин), так как материала по Java гораздо более подробные. Итак. Как нам известно виртуальная машина всегда является процессом, а потоки, выполняемые программой - наследованными процессами. Поэтому скорость выполнения того или иного потока никак не может быть величиной постоянной - в первую очередь она зависит от приоритета родительского процесса, так как приоритет порожденного процесса не может быть выше приоритета родительского. Другой фактор, от которого зависит эффективность работы JVM - количество выделенных ей ресурсов, ибо зачастую исполняемому коду отводится небольшая "песочница" где-то в памяти, из которой он выйти не в состоянии. И изминить размеры этой песочницы может только "доверенный" код. То есть только тот код, которому пользователь собственноручно разрешил изменить "песочницу". Но вылезти в основную область памяти у приложения всё-равно не получится. И третий - самый, пожалуй, неприятный, но вместе с тем, неизбежный фактор - сборщик мусора. За то, что нам не приходится каждый раз инициализировать и завершать, а потом уничтожать объекты вручную мы платим тем, чтоэтот самый сборщик мусора - есть. Именно он очищает память. Пример:
code:obj = new Object();
delete obj;
Объект считается уничтоженным, но при этом продолжает занимать память. И будет занимать память до тех пор, пока количество свободных системных ресурсов не приблизится к критической точке. И вот только тогда появляется сборщик мусора и собирает все объекты, на которые нет ни одной активной ссылки.
Вот работа сборщика мусора, в 80 процентов случаев и приводит к жутким тормозам. К сожалению, в AS возможность явного вызова сборщика мусора недокументирована, поэтому приходится обходится подручными средствами. - пересозданием объектов. Дело в том, что синтаксическая запись a=new Object (); означает, что создается новый объект Object, и переменной a присваиватся ссылка на этот объект. Пример :
code:obj1 = {param:10};
obj2=obj1;
obbj2.param = 12;
trace (obj1.param);
Выводит 12, а не 10, как можно было бы ожидать.
Но. В AS есть обходной путь. Иработает он только для объектов типа MovieClip. Дело в том, что на одном уровне глубины (depth) одновременно может существовать только один объект с уникальным именем. Но (!) при создании второго такого объекта первый - не уничтожается, а перезаписывается с новыми параметрами. То есть не происходит выделение новой области памяти. а перераспределяется старая.
Поскольку функция в AS так же считается объектом-ссылкой на область памяти - подобное прокатывает и с функциями. Другой вопрос, если мы переменной присвоим ссылку на другой объект. Тогда перезаписи не происходит и ячейка памяти остается занятой.
В таких условиях даже на одной машине в зависимости от окружения код будет выполняться разное время, а ты говоришь P166=P2400.
И еще. Я замерил присланный код на двух машинах с близкими характеристиками. Windows и FreeBSD. 11 мс и 13 мс соответственно.
Итак, к чему же всё это было сказано? А к тому, что если ты, уважаемый
xintrea, хочешь что бы тебя воспринимали всерьез, разберись, для начала с темой. А уже потом пытайся перевернуть мир. И уверяю тебя, что когды ты копнешь поглубже, переворачивать его тебе совсем не захочется
sincerely yours, Dindin
Да уж... Всего три слова - горе от ума. Не обижайтесь.
Вопрос был предельно простым и понятным. Почему ролик по ентой пресловутой ссылке крутится почти с одинаковой скоростью что на P166, что на P2400?
Дополнительная информация: P166 с 32Mb мозгов и видюхой S3TrioV64+ мягко говоря довольно сильно отличается от P2400 с 512Mb и Radeon7500. Несмотря на такие весьма большого порядка различия, ролик крутится примерно с одинаковой скоростью (различие - секунды). Винда свежезагруженная, первая запущенная пользователем программа - Flashlayer6 с этим клипом. По логике вещей скорость должна отличаться в разы, на деле - несколько процентов.
> В таких условиях даже на одной
> машине в зависимости от
> окружения код будет
> выполняться разное время,
> а ты говоришь P166=P2400.
Дорогой Dindin, в своих рамышениях вы потеряли нить разговора.
Ответа на вопрос как соптимизировать/ускорить код или переделать структуру скрипта я тоже не услышал. Между тем, на других информационных ресурсах эту тему воспринимают вполне адекватно, тем более что у людей есть схожие проблеммы и пути их преодоления.
Досвидания, дорогой Dindin.
Оригинал написал(а) Dindin
/// у буржуев чайников не меньше чем у нас, и имя "Питер Холл" без ссылки на первоисточник мне лично ни о чем не говорит. (старая сказка "а вот в развитых странах...")
http://www.peterjoel.com
Nox Noctis
24.05.2004, 11:02
Ответа на вопрос как соптимизировать/ускорить код или переделать структуру скрипта я тоже не услышал.не надо подменять контекст :) ты спросил почему так происходит на уровне плеера, а не на уровне того что под этот плеер написано.
Диньдинь очень в тему упомянул про виртуальную машину - ведь она является посредником между твоим скриптом и операционной системой. и скорость исполнения скрипта зависит от этой машины.
— если ты спросишь как ускорить виртуальную машину - ответ: не знаю. руки не доходят покопаться в СДК, может там что-то прояснится...
— если ты спросишь как ускорить код (о чем ты вообще-то не спрашивал изначально) - я скажу что нужно почитать документацию по http://flasm.sourceforge.net/ и поэкспериментировать с разными типами синтаксиса, какие коды ассемблера ВМ они генерят, какие быстрее выполняются и как их оптимизировать.
ролик крутится примерно с одинаковой скоростьюв идеалие - он должен крутиться с идентичной скоростью, если только на исполнение скрипта не требуется много большее время, чем отведено на один кадр. (кажется я уже это говорил :) ) возьми мой код бенчмарка, проверь что он выдаёт на этих машинах.
и вот это меня вообще поражает:
(различие - секунды). блин :)
если ты говоришь что скорость почти идентична - то различие должно быть в пределах 100мсек. а ты говоришь секунды :) вот оно и различие... то есть все эти слова выше не относятся к твоему эксперименту, потому что ты не верно интерпретировал результат самого эксперимента.
Между тем, на других информационных ресурсах эту тему воспринимают вполне адекватно, тем более что у людей есть схожие проблеммы и пути их преодоления.где? :)
лично я всегда рад найти и признать ошибки.
где люди говорят об этом же? просто посмотрим, сравним, проанализируем... м?
http://www.peterjoel.com/blog/?archive=2003_01_01_archive.xml - собственно говоря первоисточник, те самые буржуйские источники, на которые ссылается глубокоуважаемый xintrea.
However, that is completely wrong. Try this test:
a = [];
t = getTimer();
for(var i=0; i<100000; i++){
a[i] = 1;
}
trace(getTimer()-t); // 2555
And compare to this:
a = [];
t = getTimer();
for(var i=0; i<100000; i++){
a.push(1);
}
trace(getTimer()-t); // 2241 (!!)
If you're on a slow machine, you might like to reduce the number of loops, to prevent a script timeout.
И кто после этого говорит об одинаковом времени исполнения?
Там же под той же датой встречаем такие статьи, как:
"Flash Player Performance on OS X"
"Flash Player speed optimisations are platform dependent"
И вообще, там много решений как по оптимизации скриптов, так и по оптимизации работы плеера в разных ОС. Если уж humble opinion тех, кто отвечает Вам, уважаемый xintrea, Вас не устраивает, обращаетесь к столь любимым Вами буржуйским источникам. И не морочьте голову.
ЗЫ спасибо nuran'у за ссылку. Беру назад свои слова о чайниках
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.