2Gb хром (по новой спеке 4gb но тогда Сафари мимо), плюс на телефонах с 3Gb памяти (самсунг) можно попасть в какой-то другой лимит системы, поэтому больше гига лучше не кушать, если есть желание широкого покрытия.
Я имел ввиду, что G1GC в моем случае сам не включается. Когда все в нативной памяти очищается, память контейнера все равно прет, пока в этот цикл не вставишь ручками System.gc() и все ровненько, но мне не очень нравится принудительная сборка в цикле, другого способа не нашел.
Самые важные подводные камни: У JNI есть особенность, что ссылки на него работают только в текущем методе текущего потока, иначе почти гарантированно, что их убьет GC и будет NPE. Чем быстрее забираешь данные в нативные структуры по JNI - тем лучше.
Ну и самое главное, если вы в С++ используете фабричные методы, память нужно очищать ручками, так как рантайм java ничегошечки не знает про память в С++
Из бесячего и плохо документируемого: в зависимости от потребления native памяти, android может грохнуть предыдущие активити текущего активного приложения, если ему покажется, что нужно больше ресурсов, спасает только инициализация в application, а не в onCreate в выранной активити.
При контейнеризации приложений с JNI можно узнать много нового про GC Java, иногда его нужно дергать вручную, чтобы твои ручные очистки нативной памяти действительно срабатывали.
Спасибо, сталкивался, что G1GC в контейнере при работе с JNI лучше всего себя ведет, но делать очистку мусора приходится самостоятельно, не понимает когда "пора" и память прет.
В каких случаях система может убивать активити (не находящуюся на экране, а оставшуюся в истории навигации) не убивая процесс приложения?
Это фиксируется, но документация это отрицает
The system never kills an activity directly to free up memory. Instead, it kills the process the activity runs in, destroying not only the activity but everything else running in the process as well.
Не знаю на счет проблемы emscripten, он все же больше занимается оберточным делом и дает хорошие практики и со стороны js и при работе с памятью. Симды у ffmpeg есть только -msimd128, другие оптимизации никто руками не переписывал.
Размер в ущерб производительности. В моем случае Oz дает просадку в 20%.
Давайте возьмем реальный проект. https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.10/dist/umd/ffmpeg-core.wasm 30mb васм в зипе уменьшается практически в три раза. Он и так то значительно тормознее чем нативный, совершенно нет разницы даже в том, что он весит на 5mb больше, главное, чтобы работал быстро
В моем случае между O3 и Oz - даже нет темы для обсуждения. Производительность +20% стоит лишнего незначительного размера, который после после архивации перестает быть недостатком. И код после оптимизации не ломается.
> сильно зависит от кейса использования модулей.
WASM бинари сами по себе прекрасно сжимается, для пруфа достаточно самостоятельно сжать в zip на скоростном профиле и увидеть, какой реальный размер файла будет передан по сети.
Только O3 - это максимальная производительность и минимальный размер. Oz бесполезен полностью - просаживать производительность (минус 20% !! документация не врала) ради 5кб при том что zip архивирует в разы лучше вообще неразумно говорить об Oz.
мухожук действительно не манделла...
Волков коммандер
Это скрытое продвижение бразера Brave и Vivaldi
2Gb хром (по новой спеке 4gb но тогда Сафари мимо), плюс на телефонах с 3Gb памяти (самсунг) можно попасть в какой-то другой лимит системы, поэтому больше гига лучше не кушать, если есть желание широкого покрытия.
Я имел ввиду, что G1GC в моем случае сам не включается. Когда все в нативной памяти очищается, память контейнера все равно прет, пока в этот цикл не вставишь ручками System.gc() и все ровненько, но мне не очень нравится принудительная сборка в цикле, другого способа не нашел.
Самые важные подводные камни:
У JNI есть особенность, что ссылки на него работают только в текущем методе текущего потока, иначе почти гарантированно, что их убьет GC и будет NPE. Чем быстрее забираешь данные в нативные структуры по JNI - тем лучше.
Ну и самое главное, если вы в С++ используете фабричные методы, память нужно очищать ручками, так как рантайм java ничегошечки не знает про память в С++
Из бесячего и плохо документируемого: в зависимости от потребления native памяти, android может грохнуть предыдущие активити текущего активного приложения, если ему покажется, что нужно больше ресурсов, спасает только инициализация в application, а не в onCreate в выранной активити.
При контейнеризации приложений с JNI можно узнать много нового про GC Java, иногда его нужно дергать вручную, чтобы твои ручные очистки нативной памяти действительно срабатывали.
Спасибо, сталкивался, что G1GC в контейнере при работе с JNI лучше всего себя ведет, но делать очистку мусора приходится самостоятельно, не понимает когда "пора" и память прет.
типа того, не только под васм но и под железки
Какой CG используйте при работе в контейнере?
Кстати, зреет модульная замена libc EMCC_CFLAGS=-lllvmlibc
В каких случаях система может убивать активити (не находящуюся на экране, а оставшуюся в истории навигации) не убивая процесс приложения?
Это фиксируется, но документация это отрицает
The system never kills an activity directly to free up memory. Instead, it kills the process the activity runs in, destroying not only the activity but everything else running in the process as well.
Осталось apple не саботировать рандомный черный экран при открытии камеры из под PWA
Это давно было, asm.js уже забыт. с 19 года emscripten на
upstream LLVM WebAssembly backend. Он поддерживает нативные таргеты через upstream LLVM.
А как иначе, это же для совместимости.Разве от него можно отказаться?
Не знаю на счет проблемы emscripten, он все же больше занимается оберточным делом и дает хорошие практики и со стороны js и при работе с памятью. Симды у ffmpeg есть только -msimd128, другие оптимизации никто руками не переписывал.
Если перформанс точно не страдает - я не против, мои же тесты подтверждают мнение из документации,
https://emscripten.org/docs/optimizing/Optimizing-Code.html#trading-off-code-size-and-performance
Размер в ущерб производительности. В моем случае Oz дает просадку в 20%.
Давайте возьмем реальный проект.
https://cdn.jsdelivr.net/npm/@ffmpeg/core@0.12.10/dist/umd/ffmpeg-core.wasm
30mb васм в зипе уменьшается практически в три раза. Он и так то значительно тормознее чем нативный, совершенно нет разницы даже в том, что он весит на 5mb больше, главное, чтобы работал быстро
В моем случае между O3 и Oz - даже нет темы для обсуждения. Производительность +20% стоит лишнего незначительного размера, который после после архивации перестает быть недостатком. И код после оптимизации не ломается.
> сильно зависит от кейса использования модулей.
WASM бинари сами по себе прекрасно сжимается, для пруфа достаточно самостоятельно сжать в zip на скоростном профиле и увидеть, какой реальный размер файла будет передан по сети.
Только O3 - это максимальная производительность и минимальный размер. Oz бесполезен полностью - просаживать производительность (минус 20% !! документация не врала) ради 5кб при том что zip архивирует в разы лучше вообще неразумно говорить об Oz.
он вообще даже не запустился за пределами РФ)) Тупо белый экран и все. Win11
Сигнал на дестопе на Винде не заработал)
Какая оптика на камерах? Обычные линзы позволяют работать до 1700нм?