KDEのMéven Car氏が、Dolphinファイルマネージャ26.08とKIOフレームワークのパフォーマンス改善についてブログ2部作を執筆。小さいファイルのコピー速度が4月比で2倍以上に向上したが、cpコマンドとの性能差はまだ残っており、バッチ処理の改善が進行中と報告している。
Gunicorn の gthread worker はメインスレッドが epoll でソケットを監視しスレッドプールへ処理を振る方式で、keep-alive接続がスレッドを占有しない利点がある。ただし GIL の競合が起きやすく、nginx 等の後段では worker_connections をスレッド数と揃えないと負荷偏りが発生しうる。Python 3.14 と 3.14t（freethreading）でベンチマークした結果、3.14t は約1.76倍のRPS向上を示したが、単純な性能重視ならsync workerが最も優れ、gthreadは外部API遅延時の詰まり回避など特定用途向けの選択肢と結論づけている。
Cloudflareがパブリックリゾルバー1.1.1.1のDNSキャッシュ構造をRustレベルで見直し、Vec/Stringの固定長化、応答リストの統合、ドメイン名の重複排除、レコード種別ごとの可変長格納、通信形式でのバイト列一括保存という5段階の最適化を実施。キャッシュ1件あたりのメモリ使用量を953バイトから420バイトへ56%削減し、常駐メモリのp99は9.3GBから5.3GBに減少、書き込み性能43%向上・検索時間19%短縮を達成し、システム全体で約100TBのメモリを節約した。
Percona Server for MySQL 8.4系の3バージョン（8.4.8-8、8.4.10-10、8.4.11-11）についてsysbench OLTP Read-Writeベンチマークで性能推移を検証。8.4.11-11はInnoDB LRUページフラッシュ最適化により、スレッド数が物理コア数を超える高並行・I/Oバウンド環境で他バージョンを大きく上回るTPSを達成。8.4.10-10はPGO導入により8.4.8-8より高性能。ただしデータが完全にバッファに収まる環境では8.4.10-10がわずかに優位。
Millimanのアクチュアリーが、保険数理モデルの計算をPythonで開発しつつNumba JITでC++並みの速度を得た事例を解説。LLVMを使ったコンパイルパイプラインの仕組み、CPUで約2倍・GPU活用でさらに750倍の高速化を実現した実績を紹介する一方、型推論エラーやコンパイルオーバーヘッド、オブジェクト指向設計との相性といった制約にも言及している。
PostgreSQLでpg_sleepのみのアイドル接続がどれだけメモリを消費するかをEC2(t3.micro)上でfreeコマンドを使って検証した記事。接続数を0→51→100と増やしながらavailableメモリの減少量を計測し、1接続あたり約4.4〜4.5MiBを消費すると結論づけている。何も処理していない接続でもメモリコストが無視できないため、PgBouncerやRDS Proxy等のコネクションプーリングによる接続数管理の重要性を指摘している。
WSL2のzshで入力遅延が発生する原因はfast-syntax-highlightingがコマンド存在判定時に$PATH内の/mnt/c配下（Windows側パス）へアクセスすることにあり、/etc/wsl.confでappendWindowsPath=falseを設定してWindowsパスを除去することで解消できる。zsh-benchによる計測ではinput_lag_msが55.042msから9.831msへ大幅に改善した。
Next.js 16.3が正式リリース。Turbopackのメモリ使用量を最大90%削減し再ビルドを最大5.5倍高速化、TypeScript 7による型チェック高速化、Node.jsネイティブStream API採用でSSRを最大22%高速化した。さらにSPA並みの高速な画面遷移を実現する新機能「Instant Navigations」と、遅い箇所を検知する開発ツール「Instant Insights」を搭載した。
DuckDB v2.0では再帰CTEの実行エンジンを刷新し、各イテレーション（epoch）ごとに使い捨てていたパイプラインスケジュールやハッシュビルドなどの実行状態を、再帰不変な部分は呼び出し(invocation)スコープで再利用するよう変更した。ジョインの向きを再構成して不変な辺テーブル側をビルド側に固定する、フロンティアの実サイズに応じてinline実行とスケジュール実行を動的に切り替える、USING KEYのキー付き状態を凍結したハッシュテーブルとして直接プローブ可能にする、といった最適化により、到達可能性クエリで4.051秒から0.095秒へ42.6倍高速化した。また意味論的な変更として、USING KEY ... UNIONで実際に変化した新規/更新キーのみを次イテレーションに伝播するようにした。
gunicornにuwsgiプロトコル対応とpicohttpparser採用の高速httpパーサーが追加されたことを受け、著者がgunicornのHTTP(auto/python parser)とuwsgi protocolの性能をベンチマーク比較した記事。意外にもpure Pythonパーサーがpicohttpparser採用のfastパーサーより高速という結果になり、gunicorn_h1cのインターフェイスに余計な変換が挟まっていることが原因と分析している。性能差はどちらも実用上無視できる水準であり、将来性やエコシステムの観点から新規にはHTTPプロトコルの利用を推奨し、uwsgiは移行時の選択肢に留めるべきと結論づけている。
DuckDB Java ドライバー v1.5.3.0 で、従来の行単位 JDBC ResultSet に加えて、エンジン内部のカラムナ形式チャンクを直接読める DuckDBChunkedResult API が追加された。行→列の変換往復を省き、大規模結果セットを遅延・低オーバーヘッドで読めるが、複合型非対応など現時点では制限がある。
メルカリDBREチームによるTiDB移行改善記事の最終回。共有インデックス構成では、複合主キーや非整数主キー（common handle）を持つテーブルで、主キーのORDER BYがインデックス順として認識されずTopNによる全件読み取りが発生するというMySQLとの非互換を実行計画付きで解説し、インデックス末尾に主キーカラムを追加する対処を紹介。あわせてTiDB移行で顕在化しやすいN+1問題の改善とオプティマイザヒントによる実行計画制御についても述べている。
ISUCONに7度参加した筆者が、自身の失敗経験から得た教訓を共有する記事。変更の反映確認を怠らない、複数施策を同時に試さず1つずつベンチマークする、得意分野や面白そうな問題への執着を避けボトルネックに集中する、「あとちょっとで解ける」状態への時間浪費を防ぐため制限時間を設ける、といった具体的な対策を紹介している。