управление памятью с Flash Develop profiler

[inozemcev]

Собственно, всех кого интересует каким образом работает профайлер во FlashDevelop рассказываю:

В тот момент когда вы компилируете debug версию вашего приложения, FlashDevelop загружает вместе с вашим приложением флешку, которую он подбирает с
C:\User\%UserName%\AppData\Local\FlashDevelop\Data\As3Context\ Profiler4.swf

Эта флешка устанавливает сокет соединение, через через host:localhost, port:1978. Через которое передает список 'живых объектов'.

Формируется этот список с помощью класса Dictionary. Как вам наверное уже известно класс Dictionary можно инициировать таким образом, чтобы его свойства были слабо связанными ссылками на объекты, которые вы используете для определения этих свойств.

// создаем объект и определяем жесткую ссылку.
var someDisplayObject:DisplayObject = new Sprite () as DisplayObject ();
 
// создаем словарь
var dictionary:Dictionary = new Dictionary (true);
 
// определяем слабую ссылку на объект
dicionary[someDisplayObject] = ... (все что угодно)
 
// удаляем жесткую ссылку
someDisplayObject = null;
 
// при обходе все равно покажет спрайт, потому что GC не удаляет объекты, когда памяти еще достаточно.
for (var item:DisplayObject in dictionary)
{
     trace (item) // output [Sprite] 
}
 
//и теперь после System.gc () он наконец сможет показать, что объект удалился.

Cсылки на объекты он собирает с помощью пакета flash.sampler. Буквально так:
Запускает таймер и в хандлере таймера собирает образы, которые собираются, после того как вызвать метод flash.sampler.startSampling ();

Дальше в функции обработчике
вытаскивает объект с образами (flash.samler.getSamples())
Если образ это объект типа NewObjectSample, то вытаскивает из него ссылку на объект (судя по всему жесткую), через недокументированное свойство object и запихивает его в свой dictionary.
После этого удаляет все образы и снова стартует сборку образов.

Чтобы в образы не записывалось много внутренних образов самого профайлера, profiler приостанавливает сборку внутри той или иной функции (flash.sampler.pauseSampling) и запускает ее снова, когда выходит из нее (flash.sampler.startSampling)

Теперь выводы:

Самый главный вывод, профилировать с помощью такого профайлера нельзя или можно но с очень большим трудом. И вот почему:

1. Во первых, как бы не старался профайлер при выходе из функции гребаный флеш плеер все равно плодит никем не контролируемые объекты типа Class, Function, Namespace и.т.п Все эти объекты все равно попадают в коллекцию образов профайлера, а это в свою очередь ведет к тому, что мы получаем никому не нужные списки объектов, о которых не имеем не малейшего понятия. Профайлер конечно здесь не виноват,
потому что он делает все, что в его силах. Из Объекта Sample он достает массив stacks из которого можно определить, что послужило созданию объекта, но тем не менее, все эти объекты скорее всего убьются сборщиком мусора и потому нам совершенно не нужны. Со временем их становится так много, что за деревьями не видно леса и мы теряем из виду нужные нам объекты.

2. Совершенно непонятно почему плеер пользуется объектами actionscript когда у него есть возможность пользоваться своими собственными низкоуровневыми объектами. Я еще могу понять зачем он создает объекты LoaderInfo и ApplicationDomain при инициализации первого спрайта. Но зачем он создает функции и объекты между вызовами функций, совершенно непонятно.

3. В третьих чтобы точно выяснить, будет ли ваш будет удален нужно явно вызывать сборку мусора.

4. Обслуживание работы профайлера стоит дорого. Профайлер плодит TimerEvent и еще много всякого мусора, работает с интервалом 50 миллисекунд, при каждой иттерации обходит и создает на лету новые объекты.

Так что выводы неутешительные.

Доподлинно известно, что
плеер помечает отработанные объекты ([mark]), прежде чем когда либо их удалить ([sweep]).

Логично было бы в том же пaкете flash.sampler иметь функцию, в которую можно передать слабую ссылку на объект и выяснить помечен ли он или нет для сборки мусора. В крайнем случае, хотя это и убогий метод, можно было бы сразу же помечать объект, на который больше нет явных ссылок и добавлять метод [mark] в stacks образов, но с сожалению, этих невидимых команд там нет. Я в отчаянии.

Adobe настолько сильно увлеклись своим flex, что забыли о самом главном что у них есть pure actionscript Вместо того, чтобы делять на хрен никому не нужные компоненты flex. С куда большей пользой можно было бы предоставить адекватный инструментарий для контроля за памятью. Чуть ли не самым важным элементом в любом приложении.

[dimarik]

А правда ли, что можно управлять памятью с помощью Flash Develop profiler, как заявлено в заголовке?

[inozemcev]

Честно, уже надоело здесь что - либо писать. Я вам ничего не должен так, между прочим. У вас свое понимание процесса управления у меня свое. Формально наблюдение за памятью можно считать частью процесса управления. По существу есть что сказать ?!

[dimarik]

Я очень заинтересовался, увидев заголовок. Бегло посмотрев тему я разочаровался. Подумал, что заголовочек-то желтоват. Вот и все мое существо.

[Psycho Tiger]

Вы рассказали статью, а Ваш читатель заинтересовался главным выводом в заголовке. У Вас странная реакция.

За статью спасибо, почерпнул что-то новое.

[inozemcev]

Извините, просто в тот момент когда я ожидал поддержки, ко мне придрались по незначительному на мой взгляд поводу - это и взбесило. Но в прочем это не важно потому, что я таки докопался до истины.
Вообщем я недооценил силу flash.sampler.* Остальное напишу в блоге.

[i.o.]

ко мне придрались по незначительному на мой взгляд поводу

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