Есть один ньанс, иногда товар может быть дороже из-за качества, но советник даст товар с самой низкой ценой на товар который делает в подвале :)
В итоге такие "советники" уменьшают кол-во производителей качественного товара, что в итоге приводит к рынку состоящему из некачественной продукции производители которых кстати нанимают меньше сотрудников (а это минус раб места для страны) и платят копейки или вообще в конвертах(что тоже отражается плохо на гражданах). Вот и получается что покупатели дешевых товаров\услуг сами себе портят жизнь окружая себя все больше и больше бизнесом с низкой социальной ответственностью :)
Hyubert, что? я написал что память заполняется и крашится браузер. В этом и причина по которой хотелось бы отслеживать её и предпринимать меры. К чему эти придирки сейчас к предложениям? Выяснили уже что мы друг друга не так поняли, вопрос задан конкретно про память и возможность определить её кол-во, все остальное не важно.
Все равно я так понял возможности подобной нет. Так что будем дальше думать.
Hyubert, я и не говорил что в памяти проблема, я спрашивал можно ли знать сколько памяти тратится в текущей момент, чтобы адаптировать код, как минимум сделать отмену действий во избежание краша.
numFrames это не то. 140 фреймов 600х600px в images массиве покажет вам мой результат.
Hyubert, а теперь попробуйте увеличить размер гиф хотя бы до 1080 чтоб более менее иметь нормального качества для текущего поколения актуальных смартфонов, а не 200 на 200.
И конвертировать не видео, а набор фреймов из image около 100-200 штук. Во время сборки память стартует около 190мб, а к концу сборки на смартфоне процесс съедает около 500мб. Проверено на нескольких разных смартфонах, и часть из них средней мощности просто отключают процесс браузера.
Hyubert, ну значит мы друг друга не допоняли. Моя суть слов, что контролировать рост оперативной памяти в некоторых приложениях очень полезно и подстраивать под это работу скрипта! если вы считаете иначе пожалуйста, вам ни кто не запрещает.
Пример такого скрипта я привёл выше, если запустить его на смартфоне, есть большой шанс (особенно в 2-4 воркера), что на не самом мощном устройстве браузер просто отвалится, а иногда и на достаточно мощном смартфоне. Если бы была возможность контролировать рост памяти, это позволило бы избежать падения браузера, на менее мощных устройствах.
На этом и построен был вопрос, ничего вроде сверхъестественного.
Hyubert, а может вам? учитывая что вы мне зачем то упорно доказываете что ГПУ все делает и память в JS приложениях не используется при операциях обработки тех же gif анимаций. Или вы так и не посмотрели пример и не попробовали запустить и посмотреть на изменения в js heap при обработке? :)
Или вы просто пришли поспорить ради спора и указывать другим что у них не так по вашему субъективному мнению, отойдя и отводя меня от сути вопроса?))
Алексей Николаев, однако примера использования знания о кол-ве байтов используемых скриптом, который позволил бы совершить какое то пагубное действие вы до сих пор не привели :)
Hyubert, по поводу ГПУ есть некоторые операции так скажем которые ложатся на ГПУ. Но вопрос о памяти и естественно я говорю о хранении там информации во время обработки, я же не говорил что память это обработчик всех операций)) я говорю об её участии в процессе!
Алексей Николаев, Бред - это говорить что то не говоря о том, как это например можно использовать? Тем более в других языках эти функции есть и почему там это безопасно, а вы говорите это не безопасно?!
Hyubert, вы серьезно? для вас это открытие? изучите опен сорс проекты например yahoo/gifshot и посмотрите как устроена обработка или просто запустите тест и понаблюдайте за воркерами и памятью. Как говорится "вместо тысячи слов" :)
Hyubert, Ну по поводу ГПУ вы на практике проверьте и поймете о чем я говорил. Подобные приложения работают с памятью по большей части, так как обработка кадров и анимации происходит в памяти, и например смартфоны при нагрузке бывает просто браузер вылетает. И очистка браузером тут вообще не причем, речь шла о контроле памяти во время нагрузки и работе воркера например, а не после неё.
Алексей Николаев, ну разница думаю очевидна "прочитать из памяти" и получить методом типа performance.memory число (Int ) - кол-во байтов используемых js скриптом?! Опасности это ни какой не представляет, если сделать этот метод нормально, как в том же хром.
Hyubert, js приложения не могут загружать память? Тем более в текущих возможностях и во время когда все приложения переходят на js в том числе и различные редакторы видео, фото и прочее. Все эти приложения не плохо так могут нагрузить смартфоны и очень хорошо иметь представление о памяти во время выполнения сценария где есть нагрузка, что равномерно распределять работу воркеров и тд.
Robur, судя по ответам и комментариям его всё таки нет вообще в природе) я надеялся что кто нибудь все таки знает способ, оказалось что способа скорее всего еще не сделали.
В итоге такие "советники" уменьшают кол-во производителей качественного товара, что в итоге приводит к рынку состоящему из некачественной продукции производители которых кстати нанимают меньше сотрудников (а это минус раб места для страны) и платят копейки или вообще в конвертах(что тоже отражается плохо на гражданах). Вот и получается что покупатели дешевых товаров\услуг сами себе портят жизнь окружая себя все больше и больше бизнесом с низкой социальной ответственностью :)