Возможно ли узнать сколько памяти использует JavaScript?

Question

[Сергей]

Собственно сабж. Из того что нашел это только window.performance.memory однако во время нагрузки и без неё, значения в window.performance.memory не меняются, хотя во вкладке Memory рост памяти идёт.
Возможно кто то знает другой способ узнать кол-во используемой памяти из js?

Comments

[Strannyk]

Task Manager в браузере.

[Сергей]

Strannyk, "способ узнать кол-во используемой памяти из js"

[Strannyk]

Сергей, Ох уж эти предлоги не по назначению...

Answer 1

[Robur]

process.memoryUsage()

Хотя это в ноде, не заметил что вы про window

Comments

[Сергей]

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

Answer 2

[hzzzzl]

https://stackoverflow.com/a/36479265

So you need the --enable-precise-memory-info flag to get a more dynamic and accurate result. For security reasons, Google Chrome doesn't provide precise information via performance.memory by default.

или никак или с флагом (я не пробовал)

Comments

[Сергей]

видел такое решение, но это не применимо, в хроме и так есть Memory вкладка, а именно в js решения не найдено пока для использования в приложении на js.

[Robur]

Сергей, ну если понимать цитату буквально то как раз с этим флагом можно будет из js получить точную инфу по памяти. Другой вопрос что вы сможете сделать только в своем браузере - а у себя вы и так посмотрите.

[Сергей]

Robur, естественно. Смысла в этом решении нет, так как есть Memory в хроме об этом написано в вопросе. Нужен способ именно из js, что уже говорит о том, что всё решение должно быть только в js, а не с какими то внешними манипуляциями с браузером :)

[Robur]

Сергей, ну, найдете решение - поделитесь

[Сергей]

Robur, судя по ответам и комментариям его всё таки нет вообще в природе) я надеялся что кто нибудь все таки знает способ, оказалось что способа скорее всего еще не сделали.

Answer 3

[Алексей Николаев]

Никак нельзя. JS ограничен по всем фронтам из соображений безопасности. Там и таймеры не точные, и много чего еще. Если такая фича и была, ее давно уже прикрыли.

Comments

[Сергей]

а в чем проблема безопасности с получением значения используемой памяти скрипта в своем же окне сайта? Это же просто получение кол-ва байтов. Я удивлён что подобного не сделали, учитывая что скрипту не плохо знать кол-во памяти используемой скриптом, для возможных действий предотвращающих процесс её нехватки или просто её роста до недопустимых значений.

[Hyubert]

Сергей, о чем Вы говорите? в каком сценарии, при работе на вашем сайте, может закончиться память???
браузер сам все делает - mdn

[Сергей]

Hyubert, js приложения не могут загружать память? Тем более в текущих возможностях и во время когда все приложения переходят на js в том числе и различные редакторы видео, фото и прочее. Все эти приложения не плохо так могут нагрузить смартфоны и очень хорошо иметь представление о памяти во время выполнения сценария где есть нагрузка, что равномерно распределять работу воркеров и тд.

[Алексей Николаев]

Сергей, помнится, атака Meltdown \ Spectre в браузере была основана на микроскопической разнице во времени чтения данных из памяти. Такая тонкость, и такая сокрушительная атака. А тут "как количество памяти может навредить", да это просто мбомба.

[Сергей]

Алексей Николаев, ну разница думаю очевидна "прочитать из памяти" и получить методом типа performance.memory число (Int ) - кол-во байтов используемых js скриптом?! Опасности это ни какой не представляет, если сделать этот метод нормально, как в том же хром.

[Hyubert]

Сергей,

...на js в том числе и различные редакторы видео, фото и прочее.

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

могут нагрузить смартфоны и очень хорошо иметь представление о памяти во время выполнения сценария где есть нагрузка

Браузер делает все за вас... динамически выделяя и очищая память....

[Сергей]

Hyubert, Ну по поводу ГПУ вы на практике проверьте и поймете о чем я говорил. Подобные приложения работают с памятью по большей части, так как обработка кадров и анимации происходит в памяти, и например смартфоны при нагрузке бывает просто браузер вылетает. И очистка браузером тут вообще не причем, речь шла о контроле памяти во время нагрузки и работе воркера например, а не после неё.

[Hyubert]

Сергей,

Ну по поводу ГПУ вы на практике проверьте и поймете о чем я говорил. Подобные приложения работают с памятью по большей части, так как обработка кадров и анимации происходит в памяти

что??? .., так как обработка кадров и анимации происходит в памяти? откуда вы такое взяли?

[Сергей]

Hyubert, вы серьезно? для вас это открытие? изучите опен сорс проекты например yahoo/gifshot и посмотрите как устроена обработка или просто запустите тест и понаблюдайте за воркерами и памятью. Как говорится "вместо тысячи слов" :)

[Алексей Николаев]

Сергей, да ну, бред. Это для вас не представляет, потому что вы априори думаете ограниченно. Мозговитый хакер сможет использовать это значение в нужных целях. В любом случае, раз не сделали - значит, не нужно это. Дыра в безопасности, стало быть, появится. У нормального приложения в принципе не должно быть желания узнать это число, а если такое желание есть - я такому приложению не доверяю.

[Hyubert]

Сергей, обработка кадров точно не осуществляться в памяти, в ней хранятся только промежуточные результаты. И то с конкретным разделением - в дискретной графике используется своя память, в интегрированной выделена из оперативной под нужды ГПУ. С процессором все еще сложнее.

Ваш пример "вместо тысячи слов" сейчас буду смотреть...

[Сергей]

Алексей Николаев, Бред - это говорить что то не говоря о том, как это например можно использовать? Тем более в других языках эти функции есть и почему там это безопасно, а вы говорите это не безопасно?!

[Сергей]

Hyubert, зачем говорить если не смотрели))

[Сергей]

Hyubert, по поводу ГПУ есть некоторые операции так скажем которые ложатся на ГПУ. Но вопрос о памяти и естественно я говорю о хранении там информации во время обработки, я же не говорил что память это обработчик всех операций)) я говорю об её участии в процессе!

[Алексей Николаев]

Сергей, потому что другие языки - это другие языки, а здесь браузер. Прискорбно, что вы не понимаете разницу.

[Hyubert]

Сергей,

Бред - это говорить что то не говоря о том, как это например можно использовать? Тем более в других языках эти функции есть и почему там это безопасно, а вы говорите это не безопасно?!

В других язык где есть управления памяти используется компиляция, где в области вашей программы без перекомпиляции злоумышленник не сможет запустить свой код. А в js используется интерпретатор, построчное выполнения кода... По этому в фронтенщиков нет доступа ко многим системным api...

по поводу ГПУ есть некоторые операции так скажем которые ложатся на ГПУ. Но вопрос о памяти и естественно я говорю о хранении там информации во время обработки, я же не говорил что память это обработчик всех операций)) я говорю об её участии в процессе!

Похоже Вам нужно подтянуть базовые знания.

[Сергей]

Алексей Николаев, однако примера использования знания о кол-ве байтов используемых скриптом, который позволил бы совершить какое то пагубное действие вы до сих пор не привели :)

[Сергей]

Hyubert, а может вам? учитывая что вы мне зачем то упорно доказываете что ГПУ все делает и память в JS приложениях не используется при операциях обработки тех же gif анимаций. Или вы так и не посмотрели пример и не попробовали запустить и посмотреть на изменения в js heap при обработке? :)
Или вы просто пришли поспорить ради спора и указывать другим что у них не так по вашему субъективному мнению, отойдя и отводя меня от сути вопроса?))

[Hyubert]

Сергей, Прочитайте мои сообщения, я даже близко не об этом...

[Сергей]

Hyubert, ну значит мы друг друга не допоняли. Моя суть слов, что контролировать рост оперативной памяти в некоторых приложениях очень полезно и подстраивать под это работу скрипта! если вы считаете иначе пожалуйста, вам ни кто не запрещает.
Пример такого скрипта я привёл выше, если запустить его на смартфоне, есть большой шанс (особенно в 2-4 воркера), что на не самом мощном устройстве браузер просто отвалится, а иногда и на достаточно мощном смартфоне. Если бы была возможность контролировать рост памяти, это позволило бы избежать падения браузера, на менее мощных устройствах.
На этом и построен был вопрос, ничего вроде сверхъестественного.

[Hyubert]

Сергей, ок, оставим память в покое.
Но вы же понимаете что делает воркер? вы же говорите о Web Workers?

[Алексей Николаев]

Сергей, к сожалению, я не хакер уровня тех ребят, которые написали эксплойт для Meltdown на js. Вот у них и спрашивайте. Это будет определенно более умным ходом, нежели утверждать, что никакого вреда от такой дыры во внутренности PC не будет.

[Hyubert]

Сергей,
Запустил демку с такими параметрами

gifshot.createGIF({
    gifWidth: 200,
    gifHeight: 200,
    video: [
        'example.mp4',
        'example.ogv'
    ],
    interval: 0.1,
    numFrames: 10,
    frameDuration: 1,
    fontWeight: 'normal',
    fontSize: '16px',
    fontFamily: 'sans-serif',
    fontColor: '#ffffff',
    textAlign: 'center',
    textBaseline: 'bottom',
    sampleInterval: 10,
    numWorkers: 100
}, function (obj) {
    if (!obj.error) {
        var image = obj.image, animatedImage = document.createElement('img');
        animatedImage.src = image;
        document.body.appendChild(animatedImage);
    }
});

И спрофилировал, вот результат - https://take.ms/lswNtA

[Сергей]

Hyubert, а теперь попробуйте увеличить размер гиф хотя бы до 1080 чтоб более менее иметь нормального качества для текущего поколения актуальных смартфонов, а не 200 на 200.
И конвертировать не видео, а набор фреймов из image около 100-200 штук. Во время сборки память стартует около 190мб, а к концу сборки на смартфоне процесс съедает около 500мб. Проверено на нескольких разных смартфонах, и часть из них средней мощности просто отключают процесс браузера.

[Сергей]

Hyubert, gif 600х600px 140 кадров

[Hyubert]

Сергей, 3 раза прогнал гифку размером 1920x1080
менял только количество потоков - 2, 10, 100
https://take.ms/cPxfkP

Что говорит что проблема не в памяти, а в алгоритме обработки...

[Hyubert]

Сергей, поднял к 140 фреймам, хотя не понятно зачем так много - https://take.ms/lMVnOh

[Сергей]

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

numFrames это не то. 140 фреймов 600х600px в images массиве покажет вам мой результат.

[Hyubert]

Сергей, а это?
https://take.ms/vUidq

[Сергей]

Hyubert, что? я написал что память заполняется и крашится браузер. В этом и причина по которой хотелось бы отслеживать её и предпринимать меры. К чему эти придирки сейчас к предложениям? Выяснили уже что мы друг друга не так поняли, вопрос задан конкретно про память и возможность определить её кол-во, все остальное не важно.
Все равно я так понял возможности подобной нет. Так что будем дальше думать.

[Сергей]

Наконец то скоро это будет возможно))