Как обойти огромную стоимость памяти в FlasCC?

Question

У нас довольно обширная кодовая база, которая компилируется и начинает работать во FlasCC. Когда вы просто открываете.swf, использование памяти проигрывателем составляет ~300 МБ. Это более или менее хорошо, так как кажется, что для кода C++ доступно около 300 МБ динамически распределенной памяти.

Проблемы начинаются, когда мы создаем темы. Согласно документации, каждый поток копирует.swf в память и запускается в песочнице. Означает ли это, что каждый pthread съедает те же ~300 МБ памяти, которые использовались плеером для открытия.swf?

Кажется так. Я сделал простой тест по порождению pthreads и дампу использования памяти (что нам сообщает flash.system.System, а также CModule.ram.length). Вот журнал:

Starting 10 threads.
Memory usage: total=288MB private=335MB free=2MB CModule=33MB
Thread 0 started.
Memory usage: total=683MB private=732MB free=1MB CModule=36MB
Thread 1 started.
Memory usage: total=1071MB private=1121MB free=1MB CModule=37MB
Thread 2 started.
Memory usage: total=1459MB private=1510MB free=1MB CModule=38MB

В этот момент plash_player_debugger завершил работу (потерпел крах) без каких-либо сообщений об ошибках.

Это в основном означает, что нам не нужны потоки. После запуска 2 pthreads остается только ~50 МБ памяти, доступной для кода C++.

Adobe Scout дает немного более глубокую разбивку использования памяти. Вот что он сообщает, когда.swf работает с 2 фоновыми потоками: (картинка из того же вопроса на форумах Adobe)

Блок "Other" увеличился с 11 до 800 МБ после появления этих 2 незанятых потоков. Память собиралась в "Другие игроки" и "Без рубрики".

Итак, главный вопрос: как обойти это? Может быть, есть способ заставить работников AS3 потреблять меньше памяти?

Answer 1

Если вы рассматриваете рабочий API AS3, у вас есть возможность передать любой SWF-файл для выполнения.

Большинство примеров (в AS3) предлагают передавать текущие байты SWF, а затем использовать что-то вроде Worker.current.isPrimordial решить, что делать.

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

В частности, для вашего случая я понимаю, что это, вероятно, очень сложно, поскольку вы полагаетесь на реализацию Adobe pthread с работниками, которая, очевидно, просто передается в основной SWF-файл как работник. Кроме того, перемещение существующей кодовой базы C/C++ с использованием потоков на работников AS3 далеко не тривиально.