🔥 В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости.

Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.

Внутри — большой цикл диспетчеризации с почти 200 opcode.

И вот интересный момент: SQLite использует обычные goto, чтобы быстро прыгать между общими ветками выполнения.

➡️ В исходниках прямо написано:

«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».

По замерам разработчиков, такой подход ускоряет sqlite3_step() примерно на 1,5%.

То есть здесь читаемость сознательно пожертвовали ради производительности.

Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Как SQLite выжимает скорость: байткод, VM и goto

Некрасивый код, который делает SQLite быстрым

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Вайбкодер спалился на выдуманном стеке

Кандидат пытался пройти интервью с ИИ-помощником, но интервьюер внезапно спросил про самописные движки Ysasu Bibu и Ynna Zist.

Соискатель уверенно ответил, что работал с обеими

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ SQL-совет, который многие игнорируют: не используй `COUNT(*)`, если тебе нужно только проверить существование строки.

Часто пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 42;

А потом проверяют, больше ли результат нуля.

Но базе приходится посчитать все совпадения, хотя тебе нужна всего одна информация: есть хотя бы одна строка или нет.

Лучше использовать:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS может остановить поиск сразу после первого совпадения.

На маленькой таблице разницы почти не заметишь. На миллионах строк и частых проверках это уже может серьёзно экономить ресурсы.

Если нужен ответ «да/нет» — не заставляй SQL считать всё.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 PPT Master делает презентации из PDF, DOCX и сайтов прямо внутри Claude Code и Cursor. И на выходе это настоящий редактируемый PowerPoint

ppt-master работает как skill для AI-IDE. Можно просто написать: «сделай презентацию из этого PDF», после чего агент сам разбирает материал, продумывает структуру, собирает дизайн и экспортирует .pptx. Поддерживаются PDF, DOCX, URL и Markdown.

Самая сильная часть проекта в том, что слайды не превращаются в набор картинок. Текст, фигуры, таблицы и графики экспортируются как нативные объекты PowerPoint, которые можно открыть и вручную отредактировать. Есть шаблоны, live preview, анимации, speaker notes и даже генерация озвучки с последующим встраиванием аудио в PPTX.

Работает с Claude Code, Cursor, VS Code + Copilot и другими agent harness. Сам пайплайн выполняется локально, кроме обращений к выбранной AI-модели.

➡️ По сути:

PDF / DOCX / URL → AI-agent → структура → дизайн → настоящий editable .pptx

Автор отдельно пишет, что цель не заменить финальную ручную полировку, а убрать примерно 90% работы с пустого листа.

➡️ github.com/hugohe3/ppt-master

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Один SQL-запрос выполнялся за 298 мс.

Почти такой же - за 0,66 мс.

Разница в 451 раз из-за одной строки.

Ситуация обычная: cursor pagination, сортировка по date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро.

Но EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter.

То есть индекс есть, но запрос все равно тащит слишком много лишнего.

Проблема в условии:

`date < @date OR (date = @date AND id <= @lastId)`

Для разработчика это выглядит логично: сначала сравниваем дату, потом id.

Но для оптимизатора такой OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных.

Правильнее записать условие через tuple comparison:

`(date, id) <= (@date, @lastId)`

Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу.

И результат: 298 мс превращаются в 0,66 мс.

Индекс сам по себе ничего не гарантирует.

Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Разраб сделал интерактивный мануал, который по шагам показывает, что происходит после нажатия Enter в адресной строке браузера

Внутри прям весь путь запроса: от интерпретации ввода и DNS до TLS, HTTP и рендеринга страницы. Всего 16 этапов и 124 подшага с анимациями и объяснениями.

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Одна строка в конфиге ускорила production-ответ с 126–230 мс до менее чем 9 мс

Paweł Urbanek собрал очень практичный гайд по профилированию Rust, где оптимизации идут не по принципу «что интереснее», а по реальной отдаче.

Из кейсов:

N+1 SQL → 21 запрос превратили в один JOIN, функция ускорилась со 104 до 70 мкс.

Три последовательных HTTP-вызова → tokio::try_join!, итоговое время почти вдвое меньше.

Неправильно настроенный Brotli в maplibre/martin → скорость была всего 27,9 KB/s. Одна правка конфига дала примерно 57x ускорение, а latency упала до <9 мс.

Ещё жёстче кейс с write lock, который держали на всём HTTP round trip. После переноса блокировки P95 для читателей рухнул с 1,11 секунды до 9,42 мкс.

И отдельная классика Tokio: unbounded channel молча накопил 73 сообщения, потому что consumer не успевал. Никакой ошибки, просто медленное движение к OOM.

Полезный порядок из гайда:

сначала SQL и HTTP, потом locks и channels, и только после этого CPU profiling.

Потому что один лишний поход в базу обычно стоит дороже, чем сотни мелких оптимизаций внутри hot loop.

➡️ hotpath.rs/blog/profiling-rust-guide

#Rust #Performance #Profiling #Tokio #Backend

🫡 Всё про Data Science

🇷🇺 Читайте нас в MAX