К предыдущей теме про Go, аллокации и сбощик мусора. Go дает нам легкость написания кода - нам не нужно думать о том, где будет лежать переменная - на стеке или на куче. Как я писал выше, тут есть очевидный минус - процессорное время. Чем сложнее структура данных, тем больше вероятность ее размещения на куче, и тем больше работы будет у garbage collector по сборке мусора. Тут как раз вышла небольшая заметка от honeycomb по этой теме - https://www.honeycomb.io/blog/how-we-saved-70-cpu-60-memory-refinery Ребята снизили процессорное время и затраты памяти почти в два раза, просто перестав анмаршалить весь blob в структуру, а разбирая только часть ее полей, и при этом заиспользовали низкоуровневое API tinylib/msgp, чтобы читать типы без аллокаций в памяти. По-итогу подобная оптимизация позволяет сократить кластер нод почти в два раза без потери производительности. Для очень хорошей оптимизации иногда не нужно внедрять сложные алгоритмы или параллелить нагрузку - достаточно открыть pprof и посмотреть, сколько аллокаций делает приложение и сколько потом работает GC, чтобы эти аллокации освободить :) dev notes | golang digest