DEV_EASY_NOTES Telegram 453
Расскажу про свой проеб с памятью. Делал я одну систему для импакт анализа. В этой системе нужно было хранить Coverage, чтобы потом по нему определять, какие тесты были затронуты. Изначально структура представляла собой вот такой json:

{
"ru.package.SomeClassName": [
{
"line_number": 1,
"tests": [
{"testId": 1},
{"testId": 2}]
}
]
}

Я упростил структуру, чтобы впихнуть в пост, но суть сохранил. Поясняю: для каждого класса мы храним номера строк, и у каждой строки — массив объектов-тестов.

Загадка от Жака Фреско: где тут проблема?

Проблема в том, что у каждой строки мы храним именно объекты, которые ещё и дублируются для каждой строки. Стоит добавить какое-то поле в этот объект — и размер этого JSON сразу улетает в космос. Первая версия структуры весила 1 ГБ.

Фикс заключается в том, что мы выносим объекты тестов в отдельный массив, а в строках оставляем только ID. Это уже позволило сократить размер в 4 раза.

Затем я подумал: «Вот, Google же придумал более оптимальный формат — Protobuf. Бинарный формат, который вообще должен ещё в разы сократить Coverage».

Я был мал и глуп, не видал больших залуп, поэтому просто перевёл структуру на Protobuf. В kotlinx serialization это делается просто подключением зависимости.

После Protobuf структура стала весить около 200 МБ. Не значительная экономия памяти, но неплохо. Я решил, что это максимум, который можно выжать. Инфра у нас быстрая, Coverage скачивался за секунды, и я не видел смысла что-то ещё копать.

До того момента, пока не пришёл матёрый iOS-ник и не сказал:

— Ты шо, ебанутый? Почему просто не использовал gzip?

Честно говоря, у меня не было ответа на этот вопрос. Я почему-то думал, что Protobuf эффективнее gzip. Однако на самом деле Protobuf вообще не про компрессию — он вообще другие проблемы решает.

Попробовал я gzip на нашей структуре. Угадаете результат?

Да, 20 МБ.

Дэээ… Что сказать… Скиллов убавилось, количество хромосом возросло.

Поэтому перед переходом на модные структуры пробуйте для начала дедовские методы — они чаще всего работают лучше.
😁4615🔥3🥰2🤡1



tgoop.com/dev_easy_notes/453
Create:
Last Update:

Расскажу про свой проеб с памятью. Делал я одну систему для импакт анализа. В этой системе нужно было хранить Coverage, чтобы потом по нему определять, какие тесты были затронуты. Изначально структура представляла собой вот такой json:

{
"ru.package.SomeClassName": [
{
"line_number": 1,
"tests": [
{"testId": 1},
{"testId": 2}]
}
]
}

Я упростил структуру, чтобы впихнуть в пост, но суть сохранил. Поясняю: для каждого класса мы храним номера строк, и у каждой строки — массив объектов-тестов.

Загадка от Жака Фреско: где тут проблема?

Проблема в том, что у каждой строки мы храним именно объекты, которые ещё и дублируются для каждой строки. Стоит добавить какое-то поле в этот объект — и размер этого JSON сразу улетает в космос. Первая версия структуры весила 1 ГБ.

Фикс заключается в том, что мы выносим объекты тестов в отдельный массив, а в строках оставляем только ID. Это уже позволило сократить размер в 4 раза.

Затем я подумал: «Вот, Google же придумал более оптимальный формат — Protobuf. Бинарный формат, который вообще должен ещё в разы сократить Coverage».

Я был мал и глуп, не видал больших залуп, поэтому просто перевёл структуру на Protobuf. В kotlinx serialization это делается просто подключением зависимости.

После Protobuf структура стала весить около 200 МБ. Не значительная экономия памяти, но неплохо. Я решил, что это максимум, который можно выжать. Инфра у нас быстрая, Coverage скачивался за секунды, и я не видел смысла что-то ещё копать.

До того момента, пока не пришёл матёрый iOS-ник и не сказал:

— Ты шо, ебанутый? Почему просто не использовал gzip?

Честно говоря, у меня не было ответа на этот вопрос. Я почему-то думал, что Protobuf эффективнее gzip. Однако на самом деле Protobuf вообще не про компрессию — он вообще другие проблемы решает.

Попробовал я gzip на нашей структуре. Угадаете результат?

Да, 20 МБ.

Дэээ… Что сказать… Скиллов убавилось, количество хромосом возросло.

Поэтому перед переходом на модные структуры пробуйте для начала дедовские методы — они чаще всего работают лучше.

BY Dev Easy Notes


Share with your friend now:
tgoop.com/dev_easy_notes/453

View MORE
Open in Telegram


Telegram News

Date: |

It’s yet another bloodbath on Satoshi Street. As of press time, Bitcoin (BTC) and the broader cryptocurrency market have corrected another 10 percent amid a massive sell-off. Ethereum (EHT) is down a staggering 15 percent moving close to $1,000, down more than 42 percent on the weekly chart. Each account can create up to 10 public channels The public channel had more than 109,000 subscribers, Judge Hui said. Ng had the power to remove or amend the messages in the channel, but he “allowed them to exist.” The court said the defendant had also incited people to commit public nuisance, with messages calling on them to take part in rallies and demonstrations including at Hong Kong International Airport, to block roads and to paralyse the public transportation system. Various forms of protest promoted on the messaging platform included general strikes, lunchtime protests and silent sit-ins. Find your optimal posting schedule and stick to it. The peak posting times include 8 am, 6 pm, and 8 pm on social media. Try to publish serious stuff in the morning and leave less demanding content later in the day.
from us


Telegram Dev Easy Notes
FROM American