Обмануть мусорщика
 

На сколько я знаю, Garbage Collector кушает много процессорного времени.

Какие есть способы его хитрого использования? Знаю, есть, например, пул объектов. А ещё?.. Можно вообще вырубить GC, и удалять объекты вручную, вызывая какие-нибудь его методы?

Можно обмануть его, сохранив ссылки на все объекты и кучу слушателей к ним ;)

Что он там кушает никого не волнует, пока Вы не запускаете шаттл.
Вырубить нельзя, и слава богу.

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

А нет возможности спровоцировать его на удаление объекта по ссылке? Взяв на себя обязанность учитывать все конфликты?

Можно сказать, что это предстоит...

Тут все это раз десять уже обсуждалось.
Вот такая статья есть: http://easyflash.org/flashlearn/flas...-pamyatyu.html
Еще кое-что в том же духе.

Но, честно говоря, все это от лукавого. На мощных компьютерах это будет незаметно, а на слабых не спасет.

Возможности нет.
Что ж Вы там такое делаете что о GC беспокоитесь?

Физический движок пишу. А возможность кое-что сделать есть... По ссылке.

Добавлено через 1 минуту
mikhailk, спасибо за ссылку. Помогла

У меня слабая машина. Исповедую следующий принцип: если идёт у меня, значит пойдёт где угодно.

А нагрузки бывают большими и на мощные машины…

не факт
у какого-нибудь пользователя будет открыто еще десять вкладок с пятью играми в браузере и все равно будет дергаться

semenyakinVS, расскажите про физический движок?

CCD используете?

Просмотрел.
И что же возможно сделать с памятью?

Что это такое, CCD? Я пока пишу логику.

Добавлено через 1 минуту
Работать без коллектора. Не вызывать уничтожения данных, кэшируя их.

И наблюдать как планка памяти растёт вверх?
Нет, спасибо.

Кстати зря вы так. Я сам реализовывал свой GC для кэширования битмапов. У меня хранился счётчик "пользователей" битмапа, если был не нужен - убивал (dispose).
Но дефактовый коллектор я никак не трогал... пусть живёт себе.

Это совсем другое.

Я имел в виду вызывать уничтожение объекта с умом и поменьше пользоваться конструкторами.

Добавлено через 5 минут
О!.. Что-то вроде такого я и имел в виду. Надстраивать стандартный GC своим.

Dispose это функция GC?

dispose это метод BitmapData.

Управлять gc можно только в дебаг-версии.

Кстати, по-поводу приблуды MemoryController. Она использует старый хак с LocalConnection. Нет никакой уверенности, что его не пофиксят в очередной версии плеера. Так что, ненадежно все это и не нужно, по-большому счету. Есть и более цивилизованные методы оптимизации.

Если так хочется дергать gc, то лучше воспользуйтесь этим.

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

А есть ли возможность чистить память "по команде"? Чтоб было привязано к какому-то событию.

А зачем?

System.gc()

+ объяснение каждому пользователю как установить дебаг плеер

in4core как всегда все разрулил )

Для расчетов можно сделать свой GC на основе битмапдат

Создаем битмапдату заполняем ее своими числами ( битмапдата это просто двухмерный массив где каждая его ячейка может принимать числа от 0 до 4 294 967 295 (uintMAX) если расчеты имеют знак числа ( типа отрицательное/положительное ) или числа с запятой, можно сохранить и вынуть знак и флоат значение через битовые операции ) после того как данные не нужны вызываем dispose()

UPD изменил сообщение так как сам проверил, битовые операции в флеше шикарно позволяют сохранить как флоат так и его знак...

Вот засорение памяти из за простых типов меня как то совсем не волнует)

Работает только в дебаг-плеере.

Сиплюсплюса на вас нет)
Научились бы как убирать за собой!
Разве сложно сделать свой метод destroy который будет подчищать?

@Котяра Не вижу проблем, помоему большенство уже делает destroy() метод, причем с таким же названием ))) Но автор видимо именно ГЦ ждет, самому не охота чистить

Это для игры а ля королевство и т.п. становится основным фактором.
upd предвижу очень большие траблы с утечкой графической памяти с этим пресловутым молехиллом..
Я уже добился краша графсистемы )) но я просто тестил - реально никто в эту нору лезть глубоко не будет, кроме разработчиков дижков.

Не только.
Например, автомобильные гонки на базе какого-нибудь 3D-движка вроде Альтернативы.
Там при построении карты для одной трассы суммарный объем используемых битмапдат может быть и 200Мб и больше. Если перед заездом на новой трассе не прибивать полностью старую, плеер легко забирает под себя всю память, до которой дотянется. :)

Ну придёт ГЦ. Посмотрит на кучу ссылок на объекты, которые повисли в памяти (хотя программист хотел их удалить), скажет чтоб мы шли в пень.