Блог*

#prog #article Shrinking your code review

It's an unfortunate reality, but one of the few things we know about software quality is that lines of code is positive correlated with bugs, <...>. Code review faces a similar challenge: the larger a patch you're reviewing, the less effective your code review is <...> Fundamentally there's only two ways to get smaller reviews: write less code or split your changes up across multiple reviews. I'm not going to focus on writing less code, a great much about has been written about this topic. Instead I'm going to focus on how to split up your changes.

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

#game #video #suckassstory https://vxtwitter.com/BazingaGamingTV/status/1903439520487416164

#music Буквально любимый трек в One finger death punch. Жаль, что в игре урезанная версия. https://jessevalentinemusic.bandcamp.com/track/shaolin-warrior

Тут Флант Prometheus форкнули переписали с кучей оптимизаций. Пост на Хабре большой с кучей подробностей + провели сравнение с VictoriaMetrics. Сам я ещё, естественно, не успел попробовать, но выглядит многообещающе

Если подобным образом проанализировать все лейблы на реальных данных, получится, что:

- 32,7 % из них имеют всего одно возможное значение, например true или 0;
- 60 % — от 2 до 255 значений, то есть укладываются в 1 байт;
- 7,3 % — от 256 до 5275 значений;
- 0 % — больше 65 535 значений. 

Это значит, что все возможные значения укладываются в два байта. 

Мы решили хранить все ID (#0, #1, #2 и т. д.) не в четырёхбайтных значениях, а как два бита, указывающие количество байт, в которые укладывается число, плюс значение. 

Это дало нам очередной выигрыш по памяти — теперь весь labelset для 1 миллиона метрик стал занимать 30 МБ. Это в 30 раз лучше стартовых 762 МБ.
. . .
Оптимальное хранение строк дало приличный выигрыш и в индексе. Если раньше в нём были строки и хэш-таблицы, которые не особенно оптимально хранятся в памяти, то в нашей реализации есть ID, которые выдаются по порядку. Это позволяет хранить в кэше четырехбайтные числа uint32 и заменить хэш-таблицы на sparse-векторы и Bitset. 

В итоге основным потребителем памяти у нас стали точки. Prometheus хранит их достаточно компактно: он использует Gorilla Encoding и битовые операции. Это не значит, что оптимизировать нечего, но для этого надо внимательно посмотреть на данные. 
. . .
Оказалось, что уникальных последовательностей временных меток всего 10 % от миллиона. Эта оптимизация позволила выиграть 55,5 % по памяти просто за счёт дедупликации.
. . .
После всех преобразований мы получили выигрыш по хранению точек почти в три раза: изначальные 787,72 МБ превратились в 283,9 МБ. При этом чем больше данных и серий, тем лучше срабатывает наша оптимизация. Если на одном миллионе метрик мы выиграли по хранению точек в 2,7 раза, то на трёх миллионах это будет уже три с небольшим раза.
. . .
В процессе работы Prometheus пишет WAL. Мы оптимизировали журнал предзаписи примерно в 19 раз. Изначальные 6,2 ГБ без сжатия в Prometheus v2 для 1 миллиона метрик превратились в 153 МБ в Deckhouse Prom++. 

Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза https://habr.com/ru/companies/flant/articles/878282/ + Deckhouse Prom++ https://github.com/deckhouse/prompp/ Чат: @prom_plus_plus

#prog А ещё, так как форк открытый, это и #amazingopensource

#ойти #хуи

r/outside

A subreddit for Outside, a free-to-play MMORPG with 7 billion+ active players.

#prog #abnormalprogramming #video

#prog #article Premature optimization

Good optimization improves the right things, at the right time, and with reasonable trade-offs. <...> Premature optimization is when at least one of the following is true: 1. Changing the wrong thing. <...> 2. Picking the wrong time. <...> 3. Choosing the wrong trade-offs. <...>

Завтрак Rust-разработчика

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