#ссылка дня
Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.
Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks
Он пока небольшой, но уже есть достаточное количество примеров, от неверной проверки статуса запроса, до дырявого сервиса кеширования.
Не позволяйте памяти утечь, котаны! И дополняйте примеры :)
#javascript #memory
Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.
Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks
Он пока небольшой, но уже есть достаточное количество примеров, от неверной проверки статуса запроса, до дырявого сервиса кеширования.
Не позволяйте памяти утечь, котаны! И дополняйте примеры :)
#javascript #memory
👍18❤4
#статья дня
Даже две!
Не так давно Джейк Арчибальд обнаружил ситуацию, с которой не справляются сборщики мусора ни в одном из известных браузерных движков.
Конечно, сама ситуация довольно странная, и выглядит так: если у вас имеется замыкание, в котором вы обратились к некоему объекту, после выполнения функции в замыкании выделенная память не очистится. Вот: https://jakearchibald.com/2024/garbage-collection-and-closures/
То есть у нас не утечка памяти, но «захват и удержание»:
В случае, когда у нас нет возвращаемой функции отмены — замыкания не создаётся и сборщик мусора отлично работает.
Так вот, Нико Прананта нашёл решение для данного конкретного случая! И решение это потрясающее: нужно оставить ссылку на буфер за пределами замыкания: https://www.nico.fyi/blog/memory-issue-in-javascript-and-closures
А как это сделать?
Передать буфер следующим аргументом в setTimeout!
Я рекомендую пробежаться по обеим статьям, но статья Нико содержит в себе ещё и описание методов отладки таких случаев, что может пригодиться.
В любом случае, даже если с буферами работать не придётся — надо иметь в виду, что это касается любых больших объектов, и кажется разумным использовать способ с передачей их через аргумент, а не замыкание.
#js #memory #performance
Даже две!
Не так давно Джейк Арчибальд обнаружил ситуацию, с которой не справляются сборщики мусора ни в одном из известных браузерных движков.
Конечно, сама ситуация довольно странная, и выглядит так: если у вас имеется замыкание, в котором вы обратились к некоему объекту, после выполнения функции в замыкании выделенная память не очистится. Вот: https://jakearchibald.com/2024/garbage-collection-and-closures/
То есть у нас не утечка памяти, но «захват и удержание»:
function demo() {
const bigArrayBuffer = new ArrayBuffer(100_000_000)
const id = setTimeout(() => {
console.log(bigArrayBuffer.byteLength)
}, 1000)
return () => clearTimeout(id)
}
globalThis.cancelDemo = demo();
В случае, когда у нас нет возвращаемой функции отмены — замыкания не создаётся и сборщик мусора отлично работает.
Так вот, Нико Прананта нашёл решение для данного конкретного случая! И решение это потрясающее: нужно оставить ссылку на буфер за пределами замыкания: https://www.nico.fyi/blog/memory-issue-in-javascript-and-closures
А как это сделать?
Передать буфер следующим аргументом в setTimeout!
function demo() {
const bigArrayBuffer = new ArrayBuffer(100_000_000)
const id = setTimeout(
(buffer) => {
console.log(buffer.byteLength)
},
1000,
bigArrayBuffer
)
return () => clearTimeout(id)
}
globalThis.cancelDemo = demo()
Я рекомендую пробежаться по обеим статьям, но статья Нико содержит в себе ещё и описание методов отладки таких случаев, что может пригодиться.
В любом случае, даже если с буферами работать не придётся — надо иметь в виду, что это касается любых больших объектов, и кажется разумным использовать способ с передачей их через аргумент, а не замыкание.
#js #memory #performance
❤12👍7
#статья дня
Недавно мы обсудили ситуацию утечки памяти, с которой не справляется ни один сборщик мусора ни в одном из существующих браузерных движков: https://t.me/htmlshit/3033
Закономерный вопрос, а как же вообще происходит эта самая сборка мусора и чистка памяти?
На это у нас есть ответ! Статья, конечно, хардкорная: https://blog.frontend-almanac.com/v8-garbage-collection
Но даже с целью общего образования работает очень хорошо. Зайти можно даже с минимальным пониманием принципов работы указателей в любом из системных языков.
Кстати, автора зовут Артем Антипин, у него есть и русскоязычная версия этой же статьи: https://blog.frontend-almanac.ru/v8-garbage-collection
#memory #cpp
Недавно мы обсудили ситуацию утечки памяти, с которой не справляется ни один сборщик мусора ни в одном из существующих браузерных движков: https://t.me/htmlshit/3033
Закономерный вопрос, а как же вообще происходит эта самая сборка мусора и чистка памяти?
На это у нас есть ответ! Статья, конечно, хардкорная: https://blog.frontend-almanac.com/v8-garbage-collection
Но даже с целью общего образования работает очень хорошо. Зайти можно даже с минимальным пониманием принципов работы указателей в любом из системных языков.
Кстати, автора зовут Артем Антипин, у него есть и русскоязычная версия этой же статьи: https://blog.frontend-almanac.ru/v8-garbage-collection
#memory #cpp
👍22
#такое дня
Тринадцать лет назад я работал в горнодобывающей/камнеобрабатывающей компании и пилил всякие инхаус-проекты: от учёта блоков, добытых на карьере, до их продажи, каталогизации, распиловки. Вплоть до визуального конструктора надгробий (на котором тщетно пытался сделать бизнес, но сегодня не о нём).
И вот сегодня в девять утра позвонил бывший коллега. С проблемой🫠
Итак: не грузятся продажи больше, чем за пару дней. Сервер выбивает в пятисотую.
Начал диагностику и понял, что падает по памяти. Причём, не потому что много продаж, а потому что может быть много блоков в продаже.
Ну а памяти-то там кот наплакал. Как крутилось на шаред-хостинге со 128 мегабайтами памяти на PHP 5.3, так и крутится.
Как оказалось, я образца 2012 года, для подсчёта продаж просто грузил в памяти вообще все блоки, а потом их уже фильтровал и считал объёмы.
Казалось бы, какая фигня, скажете вы, ну сколько там тех блоков?
Ну так-то за 13 лет добыли почти 24000 блоков и совершили несколько тысяч продаж. А каждый блок — специфика работы — должен был сохранять историю изменений, распилов, расколов и так далее... Ревизии, короче. Это довольно ощутимый объём данных.
Сначала я предложил просто убрать статистику. Но оказалось, это едва ли не самая нужная фишка — даёт моментальную видимость по контрагенту.
Естественно, код был переписан самым простым способом — пакетной обработкой. Грузим по 5000 блоков, считаем объём. И всё прекрасно заработало.
Это, к слову, о преждевременной оптимизации. Довольно плохой масштабирующийся код прекрасно работал в не самой маленькой компании 13 лет :)
Такой вот blast from the past, ничего не скажешь. Кто бы вообще мог подумать, что это всё будет работать столько лет без проблем.
#php #memory
Тринадцать лет назад я работал в горнодобывающей/камнеобрабатывающей компании и пилил всякие инхаус-проекты: от учёта блоков, добытых на карьере, до их продажи, каталогизации, распиловки. Вплоть до визуального конструктора надгробий (на котором тщетно пытался сделать бизнес, но сегодня не о нём).
И вот сегодня в девять утра позвонил бывший коллега. С проблемой
Итак: не грузятся продажи больше, чем за пару дней. Сервер выбивает в пятисотую.
Начал диагностику и понял, что падает по памяти. Причём, не потому что много продаж, а потому что может быть много блоков в продаже.
Ну а памяти-то там кот наплакал. Как крутилось на шаред-хостинге со 128 мегабайтами памяти на PHP 5.3, так и крутится.
Как оказалось, я образца 2012 года, для подсчёта продаж просто грузил в памяти вообще все блоки, а потом их уже фильтровал и считал объёмы.
Казалось бы, какая фигня, скажете вы, ну сколько там тех блоков?
Ну так-то за 13 лет добыли почти 24000 блоков и совершили несколько тысяч продаж. А каждый блок — специфика работы — должен был сохранять историю изменений, распилов, расколов и так далее... Ревизии, короче. Это довольно ощутимый объём данных.
Сначала я предложил просто убрать статистику. Но оказалось, это едва ли не самая нужная фишка — даёт моментальную видимость по контрагенту.
Естественно, код был переписан самым простым способом — пакетной обработкой. Грузим по 5000 блоков, считаем объём. И всё прекрасно заработало.
Это, к слову, о преждевременной оптимизации. Довольно плохой масштабирующийся код прекрасно работал в не самой маленькой компании 13 лет :)
Такой вот blast from the past, ничего не скажешь. Кто бы вообще мог подумать, что это всё будет работать столько лет без проблем.
#php #memory
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20👍4
#ссылка дня
Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.
Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks
Он пока небольшой, но уже есть достаточное количество примеров, от неверной проверки статуса запроса, до дырявого сервиса кеширования.
Не позволяйте памяти утечь, котаны! И дополняйте примеры :)
#javascript #memory #бородач
Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.
Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks
Он пока небольшой, но уже есть достаточное количество примеров, от неверной проверки статуса запроса, до дырявого сервиса кеширования.
Не позволяйте памяти утечь, котаны! И дополняйте примеры :)
#javascript #memory #бородач
👍17❤6🤡1🫡1