Что такое callback в AS3?

[orcpochta]

Ну, возможно, я не правильно понял и интерпретировал слова Nox-а.

Добавлено через 4 минуты
Кстати, переменные оперативно удаляются в соответствии с видимостью благодаря тому, что лежат в области памяти, называемой "стек", а вот объекты лежат в другой области памяти - "куче". Эти области памяти организованы различными образами и чистятся тоже разными способами.

Я это вычитал в книге "Философия Java"...))))))))

[BlooDHounD]

orcpochta, ну это нормально. так вот если Event не выходит из стэка, то он удаляется сразу.

[orcpochta]

Сообщение от BlooDHounD

orcpochta, а что с ними происходит?

с кем? с объектами?

они лежат себе в куче и лежат до того момента, пока GC (собственно он только в куче и работает) не решит, что объем памяти, занимаемой объектами в куче, не начинает приближаться к общему выделенному системой для этого приложения объему памяти кучи - и вот тут-то он начинает все чистить, что не в прямой области видимости

на самом деле это утрированно, т.к. GC чистит порционально, а не все сразу, но общий смысл понятен

еще GC может вызываться в каких-то других случаях, но это частности

Добавлено через 2 минуты

Сообщение от BlooDHounD

orcpochta, ну это нормально. так вот если Event не выходит из стэка, то он удаляется сразу.

Event лежит в куче (как и любой объект-непримитив), а ссылка на него лежит в стеке

[wvxvw]

http://bugs.adobe.com/jira/browse/SDK-24249
это читать по поводу событий и производительности.
Что касается сборщика мусора, то есть два разных явления, дефрагментация памяти и объем реально используемой памяти. Т.е. не зависимо от того когда удаляется созданый объект память будет дефрагментироваться тем самым увеличивая общий объем. Дворник включается исходя из соотношения занятой памяти к доступной, так что даже если вы будете создавать и сразу удалять объекты в большом количестве то рано или поздно дворник включится.

[Psycho Tiger]

Кстати, по теме GC. Интересность нашел:

spr = new Sprite();
spr.graphics.beginFill(0);
spr.graphics.drawCircle(0, 0, 300);
spr.graphics.endFill();
super.addChild(spr);
super.addEventListener(MouseEvent.CLICK, onClick);

private function onClick(e:MouseEvent):void 
		{
			var i:int = 10000;
			while (i--) new Sprite();
		}

Смотрим профайлером: по клику скачок памяти, через секунду обратно на стартовое значение, всё хорошо. Но если в течении этой секунды нажать второй раз - наблюдается второй скачок, т.е. памяти используется больше. Назревает логичный вопрос: новый спрайт мы нигде не используем, переменные локальные и ссылок нигде не оставляем. Значит, при повтором клике эти новые спрайты должны лепиться друг поверх друга и память должна стоять на месте.
Но если эти спрайты сразу же добавить на сцену - памяти используется раз в 50 больше, что толкает на мысль - что эти скачки памяти лишь несовершенность профайлера. С другой стороны, может быть память неуспевает быть дефрагментированной и новые объекты лепятся за старыми. Где правда?

[expl]

Ну нажали второй раз - а GC еще не успел предыдущие спрайты убрать - логично
добавили на сцену - объекты попали в список отображения и обросли допольнительными обязанностями - потребление памяти возросло - тоже все логично

[Bgg]

Сообщение от orcpochta

Я это вычитал в книге "Философия Java"...))))))))

Не по теме. Тоже сейчас читаю, слово "куча" возмутило. Может быть перевод кривой?

А по теме, у меня лично никогда не стояло выбора между использованием callback'а или событий, всегда что то одно удобнее другого.

[Котяра]

Сообщение от Bgg

Не по теме. Тоже сейчас читаю, слово "куча" возмутило. Может быть перевод кривой?

Стек и куча - устоявшиеся понятия.

[Zebestov]

всегда использую события, не прыгаю с одного на другое. может для того чтобы всегда и везде точно знать, как я там организовал реакцию на те или иные события.

[Psycho Tiger]

Ну нажали второй раз - а GC еще не успел предыдущие спрайты убрать - логично

GC нету для локальных переменных.