❌

Reading view

Ваш recover() эту ошибку не поймает

В Go‑сервисе recover() может выглядеть надёжной страховкой, пока конкурентная запись в map не завершает процесс через fatal error: concurrent map writes. При этом часть гонок проходит незаметно и приводит к потере данных без единой ошибки в логах. В статье разбираемся, почему recover() не спасает в таких ситуациях, как обнаружить проблему с помощью -race и какой способ синхронизации выбрать для общей map.

Разобрать проблему
  •  

Сколько миллисекунд без читателей нужно SQLite, чтобы файл -wal перестал расти

Документация SQLite говорит, что -wal перестаёт расти, только если у читателей, которые видят кадры из -wal, бывают общие паузы, но не говорит, какой длины. Я замерил в контейнере на SQLite 3.46.1: на моём стенде хватало единиц миллисекунд — 2 мс при 50 коммитах/с, 5 мс при 1000/с, и быстрой записи понадобилась пауза шире. Без паузы три читателя по 50 мс раздувают -wal так же, как один на 20 секунд, а случайные запросы по 5 мс почти не мешали, пока база была свободна хотя бы 13% времени.

Читать далее
  •  

chunk(), lazy() и cursor() в Laravel: замеры памяти и почему chunk() теряет половину строк при обновлении

Когда в Laravel нужно обработать большую таблицу, обычно советуют «не делать all(), использовать chunk()». Совет верный, но неполный: у chunk() есть ловушка, из-за которой фоновая задача тихо обрабатывает только часть строк. Ниже замеры пяти способов обхода таблицы на 100 000 строк, разбор потери строк и правила выбора метода.

Читать далее
  •  

N+1 в Eloquent: воспроизводим на стенде, считаем запросы и закрываем регрессии тестами

Про N+1 в Laravel обычно пишут три строки про with() и расходятся. Я собрал небольшой стенд на Laravel 13 и SQLite, воспроизвёл проблему, посчитал запросы для каждого способа лечения и проверил, что «не ловится» режимом запрета ленивой загрузки. Отдельно разобрал места, где eager loading не помогает или сам создаёт нагрузку. Все числа в статье получены на этом стенде на искусственных данных.

Читать далее
  •  

Когда Python становится слишком медленным: пишем C‑расширение с нуля и сравниваем с pybind11 (бонус JIT‑компилятор)

Недавно я прочел статью про pyrusmorph — python обёртку над 30-летним с++ ядром libmorph/rus. Бенчмарки удивили: в 30 раз быстрее PyMorphy3 при обработке текста. После я задумался. Как это вообще работает? Почему мы пишем import pyrusmorph и получаем доступ к нативному с++ коду и функциям прямо внутри python.

В статье я предлагаю пройти этот путь с нуля. Разобраться, как устроен Python «под капотом», написать своё расширение на чистом C‑API, а потом посмотреть, как эту боль лечит pybind11. В конце — бенчмарки и практические советы, когда вообще стоит лезть в c++ для оптимизации. Бонус — немного о компиляторе python кода (JIT‑компилятор)

Читать далее
  •  

[Перевод] Ускоряем self-hosted Convex в два раза: AOT-компиляция TypeScript-функций в Wasm

Convex – это новый, но набирающий популярность фреймворк для реактивных веб-приложений, который позволяет писать транзакционные квери (queries) и мутации (mutations) на TypeScript с гарантиями консистентности.

Вся статья ниже относится к self-hosted версии Convex: convex-backend, а точнее, к моей пропатченной версии оного, так как “официальная” версия не пригодна к работе в продакшене и вряд ли тестировалась на сколь-нибудь нагруженном кейсе. Моя версия работает на виртуальном сервере с 32 ядрами и 64Гб памяти и обрабатывает до 15 тысяч Convex-кверей и мутаций в минуту.

Я навайбкодил convex-wasm-compiler, который компилирует Convex-квери и мутации в WebAssembly, и соответствующий патч для convex-backend, позволяющий выполнять скомпилированные в Wasm Convex-функции на файберах Wasmtime прямо в Tokio рантайме convex-backend.

TLDR: квери и мутации в среднем работают в 2 раза быстрее, хвосты задержек сократились втрое. Объём памяти, который сервер удерживает под готовые к выполнению окружения (V8-контексты или Wasm-окружения), уменьшился на 80%.

Читать далее
  •  

Ghostty 1.4: терминал ускоряется, экономит память и учится быть осторожнее

27 октября 2026 года Митчелл Хашимото выпустил эмулятор терминала с GPU-ускорением — Ghostty 1.4.0. За релизом стоят семь месяцев работы, 172 контрибьютера и 2889 коммитов. В тестах команды на macOS пропускная способность ввода-вывода выросла на 25–55%, а сжатие текстовой истории сократило занимаемую ею физическую память на 70–90%.

Откуда взялось такое ускорение, что изменилось в работе с графикой и SSH и на что обратить внимание перед обновлением? Разберём все главные изменения и их нюансы в нашем обзоре. 

Читать далее
  •  

Как мы выбирали шумоподавление для БОЛТУНа

Разобрались в подходах к шумоподавлению и собрали несколько стендов для БОЛТУНа. Попробовали выделять свой голос через VoxLock, ускорили обработку с WASM до нативного ONNX Runtime и проверили нагрузку от нескольких пользователей. Рассказываем про замеры, неудачную калибровку и почему пока занялись более лёгкой обработкой пауз.

Читать далее
  •  
❌