цикл - тормозит?
 

При сравнении быстродействия следующих кодов:

replaceImage ();replaceImage ();
replaceImage ();replaceImage ();
replaceImage ();replaceImage ();
replaceImage ();replaceImage ();

и

for (i=1;i<9;i++) {replaceImage ();}

выяснилось, что второй вариант привнешней своей красоте заметно тормознее

в чем тут дело?
ладно в цикле i=8, а если 888 ?

а ты представляешь себе 888 раз написать replaceImage (); ???
Представь КАКОГО размера у тебя будет файл? Сколько он грузиться будет... Вот и выбирай что тебе милее. =))

я занимаюсь презентациями, и мне гораздо милее скорость)))

Быстрее всего - четвёрошный синтаксис.

tellTarget, eval, setProperty etc...

Наверное, slash notation тоже.

Подробности тут.

Если напишеш 888 раз:
replaceImage ();
То файл разбухнет и ты потеряешь в скорости загрузки. Тем более, сомневаюся, что такие небольшие различия в скорости между циклом и написанием подряд столь критичны.

2Gar:
А представляешь какое это шоу - посмотреть на набивающего 888 раз одно и тоже dee2? =))
Плачу 3$, чтобы на это взглянуть. и еще 2$ за то, чтобы увидеть его в момент запуска и выполнения презентации. =))

2dee2: Ты действительно потеряешь может от силы 2 сек. Разве оно того стоит? Особенно когда тебе потребуется изменить число 888, например на 777.

2cyraxchel:
Поддерживаю ставку - но только если он все это вручную набирать будет - а не через copy-paste.

2 Gar:
:) :) И длиться будет это годами.... :)

2cyraxchel:
Вот в таких случаях скорость становится критичной!
2dee2:
Не огорчайся, мы просто прикалываемся...

:rolleyes: На ассемблере есть подобное. Сравнение, конечно, не уместно, но логика, похоже, одна и та же — выполнение команд "подряд" без перерывов на обработку цикла идет быстрее.

Меня, правда, смущает видимое различие в скорости при таком небольшом количестве итераций — видимо, уже какие-то флешевые заморочки... "Долго" работает сравнение? У ассемблера там понятные причины были... Хз.