Будни разработчика
14.7K subscribers
1.18K photos
334 videos
7 files
2.01K links
Блог Lead JS-разработчика из Хельсинки
Автор: @bekharsky

По рекламе: https://telega.in/channels/htmlshit/card?r=GLOiHluU или https://t.me/it_adv

Чат: https://t.me/htmlshitchat

№5001017849, https://www.gosuslugi.ru/snet/679b74f8dad2d930d2eaa978
Download Telegram
#ссылка дня

Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.

Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks

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

Не позволяйте памяти утечь, котаны! И дополняйте примеры :)

#javascript #memory
👍184
#статья дня

Даже две!

Не так давно Джейк Арчибальд обнаружил ситуацию, с которой не справляются сборщики мусора ни в одном из известных браузерных движков.

Конечно, сама ситуация довольно странная, и выглядит так: если у вас имеется замыкание, в котором вы обратились к некоему объекту, после выполнения функции в замыкании выделенная память не очистится. Вот: 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
👍22
#такое дня

Тринадцать лет назад я работал в горнодобывающей/камнеобрабатывающей компании и пилил всякие инхаус-проекты: от учёта блоков, добытых на карьере, до их продажи, каталогизации, распиловки. Вплоть до визуального конструктора надгробий (на котором тщетно пытался сделать бизнес, но сегодня не о нём).

И вот сегодня в девять утра позвонил бывший коллега. С проблемой 🫠

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

Начал диагностику и понял, что падает по памяти. Причём, не потому что много продаж, а потому что может быть много блоков в продаже.

Ну а памяти-то там кот наплакал. Как крутилось на шаред-хостинге со 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 #бородач
👍176🤡1🫡1