А я и не знал что бывают такие штуки:
http://stackoverflow.com/questions/2527561/is-it-p...e-to-do-a-define-in-adobe-flex
И даже отдельные препроцессоры для AS3 есть. Очень интересно, можно все настроить и использовать макросы.
Для FlashBuilder: http://blog.joa-ebert.com/2006/02/27/actionscript3-preprocessor/
Для FlashDevelop: http://www.flashdevelop.org/community/viewtopic.php?f=5&t=1188
И вообще их много.
Также макросы есть в apparat: http://code.google.com/p/apparat/wiki/MacroExpansion
Для встраивания inline функций надо использовать тулзу tdsi, которая есть здесь: http://makc.googlecode.com/svn/trunk/flash/fd_inline/tdsitest/
А ещё можно делать макросы в AS3 через gpp (http://en.nothingisreal.com/wiki/GPP).
Вот он: http://makc.googlecode.com/svn/trunk/gpp.2.24-windows/
Вот тестовый проект под FD с ним: http://makc.googlecode.com/svn/trunk/flash/fd_inline/gpptest/

Коротко резюмирую тут трюки по борьбе со сборщиком мусора виртуальной машина Flash Player. Иследования проводились только для версии 11.1 standalone debugger for win32. В следующих версиях Flash Player могли как улучшить работу с памятью так и ухудшить, но скорее всего всё осталось также. Итак, garbage collector (GC) исключительно хреново работает с памятью. Он её попросту не очищает во многих случаях или выделяет в разы больше чем требуется.

Вы наверняка знаете, что такое сильные и слабые ссылки и как GC их считает чтобы понять нужен этот объект или нет... Всё это написано во многих местах, в т.ч. в документации по AS3. Я всё это повторять не буду. Здесь описано как всё должно хорошо очищаться: http://help.adobe.com/en_US/as3/mobile/flashplatform_optimizing_content.pdf
Но нифига оно так не работает к сожалению. При соблюдении всех этих правил моя программа всё равно жрала память как сумасшедшая при загрузке, а потом Flash Player просто падал, когда кончалась физическая память в операционной системе. Вот так он работает на самом деле.

Всё началось вот с этой темы в Juick: http://juick.com/eugene20237@ya.ru/2009006 и моего вопроса на StackOverflow: http://stackoverflow.com/questions/11833009/as3-bitmapdata-memory-leaks
Почитайте, если хотите, узнаете много нового о флеше. А ещё почитайте вот эту статью о том что надо реально сделать для оптимизации по памяти на флеше.

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

• Loader в дефолтном своем применении порождает утечки памяти. Поэтому если через него загружается картинка, то надо брать её BitmapData и делать bitmapData.clone(), сохраняя в другую переменную. А потом диспозить существующую картинку в Loader, а затем делать loader.unload(). Ещё на всякий случай можно cacheAsBitmap=false.
  

  PHP:
  
  
  var bitmapData:BitmapData = (loader.contentLoaderInfo.content as Bitmap).bitmapData.clone();
  
  (loader.content as Bitmap).cacheAsBitmap = false;
  
  (loader.content as Bitmap).bitmapData.dispose();
  
  (loader.content as Bitmap).bitmapData = null;
  
  (loader.contentLoaderInfo.content as Bitmap).bitmapData = null;
  
  loader.unload();
  font>
  

  
  Только тогда он работает нормально. И то с учетом, что память очищается секундой позднее. Но очищается. Во всех остальных случаях можно сушить вёсла... При этом Loader остаётся единственным способом загружать картинки без утечек памяти.


• C Embed ресурсами всё гораздо хуже. Под них выделяется всегда в разы больше памяти (в 2 раза обычно) и далее она не очищается никогда. Поэтому просто так Embed ресурсы использовать нельзя. Причина заключается в том, что они построены на Flex-компонентах, а в них много неоптимальной фигни. Юзайте Loader. А если нужно встроить ресурс в приложение, то делайте бинарный Embded, а затем Loader.loadBytes(...). Другого пути пока не найдено.
  

  PHP:
  
  
  [Embed(source="../media/128.png", mimeType="application/octet-stream")]
  
  static private const EmbedBMP:Class;
  
  ..............
  
  loader.loadBytes(new EmbedBMP() as ByteArrayAsset);
  font>
  

  
  


• Использовать много мелких картинок - плохая идея. Флеш будет выделять больше памяти чем требуется. Если же для большой группы картинок (допустим 100 шт.) вызывается dispose(), то их память будет очищена, но не сразу, а как повезет: может через минуту или как угодно Богу Мусорщику. Если же использовать десяток больших картинок (допустим 4096x4096), то память под них будет выделять и очищаться абсолютно корректно и сразу же.


• Выделение памяти под BitmapData происходит не при создании объекта BitmapData, а при первой операции рисования на ней или копирования данных пикселей в неё. Это внутренняя оптимизация BitmapData.


• Говорят, что BitmapData иногда выделяет памяти больше чем надо из-за внутреннего мипмеппинга. Этот мипмеппинг отключить никак нельзя. Также есть информация, что он отключается, если задать размеры картинки не являющиеся степенью двойки. У меня на практике это совсем не подтвердилось, так что никакой возможности управления мипмеппингом скорее всего уже нет.


• Сюда же поделюсь опытом использования трюка с local connection. Так вот, в исходном варианте этого хака LocalConnection создаётся два раза внутри try. Мои эксперименты показали, что надо вписать там три строчки, а не две. Вот так:
  

  PHP:
  
  
  public static function freeMemoryGC(): void
  
  {
  
    // the GC will perform a full mark/sweep on the second call.
  
    try
  
    {
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
      new LocalConnection().connect('foo');
  
    }
  
    catch (e:*)
  
    {
  
    }
  
    //System.gc();
  
  }
  font>
  

  
  В этом случае вероятность очистки памяти сразу гораздо выше (почти всегда сразу очищается). Если сделать два раза эту инструкцию, но вызвать тоже самое хотя бы через 100 мс, то память также очиститься. System.gc() не использую потому что он работает только AIR или только в отладочной версии Flash Player. Кроме того советую почитать эту тему о способах принудительного пинания GC. В частности в ней есть ссылка на такой способ.

То что сейчас будет написано возможно противоречит каким-нибудь принципам "правильного" проектирования ПО, так что будьте осторожны ))

Предлагаемый подход родился в моей голове чтобы упростить доступ к объектам классов вида "синглетон". Кто не в курсе, знайте, что это классы с объектами в единственном экземпляре и временем жизни равным (или примерно равным) времени работы программы. Классический подход предлагает передавать их по цепочкам в виде параметров и хранить в объектах-клиентах посредством агрегации (в виде ссылок). Такой подход похож на прокладывание сетевых проводов, где устройства взаимодействуют лишь с соседями, прямо или косвенно соединёнными проводами. Прокладывать провода или же обеспечивать каждый раз передачу синглетона по иерархии геморно. Поэтому предлагается устроить нечто похожее на wifi-сети в проектируемой объектно-ориентированной системе. Сделать синглетоны доступными всем, посредством статической переменной (метода) - почему бы и нет?

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

Выгода от этого подхода огромна! Нет гемору с параметрами и ссылками!
Подробности описал в этой статье.

Провёл сейчас любопытные тесты поиска по строковому набору из 10 тыс. эл-тов:
DICTIONARY[]: 155 ms
ARRAY[]: 196 ms
ArrayList::getItemIndex(): 19839 ms
VECTOR::indexOf(): 9923 ms

Для 100 тыс. эл-тов:
DICTIONARY[]: 1579 ms
ARRAY[]: 1473 ms
OBJECT[]: 1539 ms
OBJECT::hasOwnProperty(): 2029 ms

Вывод: не надо даже пытаться использовать indexOf(), т.к. он ищет без хеш-таблицы. ArrayList вообще в топку. Dictionary, Array и Object абсолютно идентичны. hasOwnProperty() использовать не надо.