Автор профилировал свою многопоточную реализацию Redis на Go и обнаружил, что одна строка кода `s.kvList[k] = append(v[popped:], s.kvList[k]...)` за время бенчмарка суммарно аллоцировала 687 ГБ памяти. Реально приложение держало в памяти лишь около 4,58 МБ. В чем прикол?
Проблема была в том, что LPUSH каждый раз создавал новый массив и копировал весь существующий список, давая O(n²) по аллокациям, тогда как RPUSH использовал штатную стратегию роста слайсов с амортизированным O(1).
Замена на deque с двумя индексами, растущий от середины в обе стороны, ускорила LPUSH в 33 раза, а аллокации упали с 715 ГБ до 27 ГБ
Нужно быть внимательным
27.07.2026
Похожее
28.09.2026
C на Go
Интересный пропозал - добавить возможность сборки Go-пакетов, использующих cgo д...
25.09.2026
Бенчим джейсон
Автор на реальном API с нагрузкой 50M запросов/сутки)сравнивает производительнос...
24.09.2026
Rune
Команда Unstable Build заопенсорсила свою нативную IDE Rune, написанную на Go. ...
23.09.2026
Специализированные аллокаторы
В Go 1.27 появилась оптимизация выделения памяти для объектов размером до 80 бай...