TGViewer
optozorax optozorax @optozorax_dev · 4.63K subscribers
Post #930 6.06K
Знаете, мы, программисты, регулярно замеряем ВРЕМЯ исполнения нашего кода. Но практически никогда не замеряем ПАМЯТЬ. За исключением когда мы аллоцируем её слишком много, или когда происходят утечки (и то не всегда замечаем этого). Да и вообще в стандартной библиотеке большинства языков нет никаких инструментов для того чтобы это делать.

И вот я недавно задумался об этом и решил как-то начать замерять память, чтобы нарабатывать тут интуицию и находить инсайты по поводу того как оптимизировать код. (на эту мысль в том числе натолкнул кризис ОЗУ в мире 😅)

Первый очевидный вариант - сделать штуку, которая обходит структуры данных рекурсивно и считает сколько места они занимают в памяти. Довольно хорошо ложится на мою систему компонентов чтобы знать сколько памяти занимает каждый компонент. Но это довольно дорого по рантайм ресурсам и надо написать много кода (или сложную автогенерацию кода) для каждой используемой структуры данных.

Второй вариант я придумал вчера пока мылся в душе. Надо сделать кастомный аллокатор, который пишет в счётчик данные о том сколько байтов аллоцировано и сколько освобождено. Никак не влияет на перфоманс.

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

Зато это можно очень надёжно использовать для других замеров: сколько каждый компонент производит аллокаций и какой поток памяти он аллоцирует и освобождает за единицу своего вычисления (просто какой-то временной памяти). Эти штуки вычисляются абсолютно надёжно и они могут что-то говорить про эффективность кода.

Ну и я быстренько накодил такое окно (см. картинку), которое показывает эти обе вещи. А ещё показывает сколько программа нааллоцировала в принципе. Пока это 35мб и вполне мало, хотя мне не нравится что простая сцена уже занимает столько памяти.

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

А вообще меня смущает что я за свою карьеру программистом практически не видел грамотного опыта трекинга памяти, будь то количество аллокаций/деаллокаций внутри какой-то функции, или будь то тупо слежение за тем сколько какой-то объект занимает памяти в ОЗУ. Вот эта идея с аллокатором пришла мне в душе из космоса, ни в статье, ни в твиттере я ничего такого не видел раньше. И ни у меня, ни у моих знакомых нет никакой интуиции что сколько памяти занимает.

А вы хоть раз замеряли память своего кода, или количество аллокаций?
  • ❤ 60
  • 👍 15
  • 🔥 13
  • 🤔 2
  • ⚡ 1
  • 🥰 1
More from @optozorax_dev
  1. Sep 11, 2026Там в стиме вышло демо стрелочек! https://store.steampowered.com/app/5193870/Logic_Arrows_…
  2. Sep 9, 2026https://openai.com/index/collatz-conjecture-solution
  3. Aug 20, 2026Ожидание: сделаю видео в 3D, просто отрендерю сцены в стерео и дело в шоколаде, заработаю…
  4. Aug 13, 2026Недавно я навайбкодил VR-версию моей программы Portal Explorer. Скачать можно тут: https:/…
  5. Aug 7, 2026Post #941
  6. Aug 7, 2026Следующее видео будет про червоточины! Вот вам кадры основной сцены. Очень сильно заморочи…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →