наткнулся тут на Prophetic - штуку, которая пытается научить тебя управлять снами

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

сейчас это выглядит как "прикольный гаджет для осознанных снов" (и честно, пока прям немного sci-fi), но мне больше интересен сам концепт

если такие штуки реально научатся достаточно точно влиять на состояние мозга, дальше открывается ОЧЕНЬ много всего - от сна до концентрации/памяти и тд

в общем слежу, очень интересно, куда это всё придёт

окак

сколько стоит указатель [кейс discord на Go 1.27.1]

одни и те же 10 млн записей в Go стоят сборщику мусора то 1,2 мс, то почти секунду разметки на каждую сборку

всё упирается в то, как данные разложены в куче.
но размер кучи цену почти не предсказывает - важнее, сколько внутри объектов и указателей.

— введение в домен

LRU-кэш - кэш с лимитом: когда он полон, выкидывается запись, которую дольше всех не трогали.

обычно это map + двусвязный список, то есть на каждую запись несколько объектов и указателей между ними.

сборщик ищет живые объекты так: идёт от стеков горутин и глобальных переменных по указателям и помечает всё, до чего дошёл (mark).

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

— в 2020 discord переписали сервис Read States с Go на Rust

у них раз в две минуты был спайк CPU и задержки.
сервис держал LRU-кэш на миллионы записей и почти не аллоцировал, так что сборки запускал сам рантайм по времени.

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

это правило (forcegcperiod), кстати, живёт до сих пор, в Go 1.27.1 (те же две минуты)

— что я проверил на Go 1.27.1

10 млн записей ReadState (два числа, 16 байт) в четырёх раскладках, каждая следующая убирает один источник указателей.

как был устроен кэш у discord, они не публиковали, поэтому первая строка - моя модель LRU, как его обычно пишут

                       объекты  хип     mark
LRU на указателях      25 млн   1,1 GB  974 мс
map[uint64]*ReadState  10 млн   441 MB  515 мс
map[string]ReadState   5 млн    716 MB  364 мс
map[uint64]ReadState   33 тыс.  426 MB  1,2 мс

mark - разметка одной сборки по времени, медиана трёх прогонов, кэш синтетический, без запросов и вытеснения
[i7-6700, Linux, GOMAXPROCS=8]

с Go 1.26 по умолчанию включён Green Tea GC, он сканирует мелкие объекты пачками по страницам памяти,
так что это ни разу не воспроизведение discord

я проверял, жив ли эффект на современном рантайме

спойлер, жив: Green Tea помогает (и с выключенным тот же LRU размечался за 2,7 секунд)

— сравни вторую и последнюю строку

441 MB и 426 MB - памяти почти поровну, а разметка 515 мс против 1,2 мс.
во второй 10 млн отдельных объектов, и сборщик бегает за каждым по указателю.
в последней указателей ноль, значения лежат прямо в map, и вся эта память noscan

третья строка - ловушка: * в коде нет, а указатели есть
string внутри это указатель на байты, и такие же прячутся в слайсах, map, any, time.Time

— почти секунда при этом не секунда простоя

STW-паузы меньше 0,1 мс, разметка идёт в фоне на ~2 CPU из 8, но под нагрузкой эти CPU делились бы с запросами,
а аллоцирующие горутины рантайм заставлял бы помогать разметке (mark assist) - вот и задержки

— подробно всё на странице замера

• почему у каждой строки столько объектов и что там с третьей;
• что с этим делать: значение вместо указателя, ключ числом, связи через индексы;
• как затестить у себя через runtime/metrics, pprof и gctrace;
• методика, рост с размером кэша, графики, код, логи и словарик всех терминов;

тык