テーマ： performance

• 本番環境での継続的プロファイリング: 常時稼働のサンプリングプロファイルが何に答えるか

  継続的プロファイリングはCPUやメモリのプロファイルを時系列で体系的に取得し、ラベル付きの系列として保存する。これにより、昨日フリート全体でどの関数が最もCPUを消費したか、2つのバージョンの間で何が変わったかといった問いに答えられるようになる。サンプリングプロファイラであれば常時稼働させても十分に低コストで済み、Goの`/debug/pprof/`のようなランタイムエンドポイントやeBPFエージェントがプロファイルを供給する。

  article · ja · reviewed · 知識の基準日 2026-09-16

• Summarizing time in system calls with strace -c, its overhead, and perf trace as an alternative

  strace -c counts time, calls and errors per system call instead of printing every call, but strace's own manual warns that a traced process runs more slowly than an untraced one; perf trace, described as a strace-inspired tool built on perf_events rather than ptrace, is the lower-ceremony alternative when that overhead matters.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• 変更をベンチマークする: ウォームアップ、繰り返し、ばらつき、何を報告すべきか

  タイミングの比較は、ノイズに埋もれずに残ったときだけ結果と呼べる。ワークロードを固定し、ウォームアップの実行を捨て、各バリアントの実行を多数回インターリーブし、データを見る前にどの統計量を使うか決め、すべての数値のそばにばらつきと実行環境を書き添える。実行ごとのばらつきより小さな差は、発見とは呼べない。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• A first look at Solaris performance: prstat, vmstat, mpstat, iostat and zpool iostat

  prstat -a/-Z, vmstat, mpstat, iostat -xnz and zpool iostat are five read-only commands that cover most first-look performance questions on Solaris 11.4, with zone-aware and disk-latency detail that the similarly-named Linux tools present differently.

  article · en · reviewed · 知識の基準日 2026-09-24

• 性能ボトルネックを見つける USE メソッド

  CPU、メモリ、ディスク、ネットワーク、ロックなど、各リソースの利用率、飽和、エラーを調べる。USE メソッドは、アプリケーション層で推測を始める前に、ボトルネックを素早く見つけるチェックリストである。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• レスポンス圧縮：行う場所と除外すべきもの

  テキストのレスポンス（HTML、JSON、Markdown）はプロキシかアプリケーションで圧縮し、圧縮済みの内容とストリーミング内容は除外する。エンコーディングが違っても ETag が正しく表現を示すようにし、Vary: Accept-Encoding を設定する。

  article · ja · reviewed · 知識の基準日 2026-09-15

• How much of an agent's context is tool output in real runs, and does trimming it change task success?

  Open question: the MCP specification says clients should validate tool results before passing them to the model but leaves the amount to the client; in recorded agent runs, what share of tokens is tool output rather than instructions or reasoning, and does truncating, summarising or filtering tool output change task success, cost and latency?

  question · en · reviewed · 知識の基準日 2026-09-16

• srcset、sizes、picture によるレスポンシブ画像

  幅記述子付きの srcset と sizes 属性により、ブラウザーは現在のビューポートと画素密度で表示領域を満たす最小の画像ファイルを選べる。x 記述子は固定表示サイズに複数密度を用意し、source を持つ picture は構図の切り替えと形式のフォールバックを扱う。読み込み中のレイアウトずれを防ぐため、width と height を保つ。

  article · ja · reviewed · 知識の基準日 2026-09-16

• Sampling Windows Server performance counters with Get-Counter and exporting them to CSV

  Get-Counter samples named counter paths at a chosen interval, continuously or for a fixed count; Export-Counter (Windows PowerShell 5.1 only) preserves every field in the native BLG format, and relog converts a capture to CSV afterwards even without the original Export-Counter command.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• 生成・批評・修正：自己検証ループがコストに見合う条件

  モデルが自分の出力を批評して修正するループは、批評に外部の手掛かり（テスト、バリデーター、出典）と固定した評価基準がある場合に結果を改善する。そうした裏付けがない場合には回答を悪化させ得ることが公表研究で示されており、各ラウンドでは少なくとも二回の呼び出しが増え、その入力は草稿とともに大きくなる。

  article · ja · reviewed · 知識の基準日 2026-09-16

• VACUUM、autovacuum、テーブルの肥大化

  PostgreSQL の MVCC では、更新や削除の後に不要な行バージョンが残ります。VACUUM はそれらを回収し、統計情報の維持とトランザクションIDの周回対策を行います。autovacuum は有効なままにし、更新の多いテーブルに合わせて調整します。

  article · ja · reviewed · 知識の基準日 2026-09-15

• Webフォントの読み込み：font-display、preload、unicode-rangeのサブセット、メトリクスを合わせた代替フォント

  最初の描画で文字を表示し、ブランドフォントの読み込みによるレイアウトの跳ねを防ぎます。unicode-rangeで文字体系ごとに分け、使うものだけを取得し、役割に応じてfont-displayを選びます（本文はoptional、見出しはswap）。初回用ファイルをcrossorigin付きで先読みし、size-adjustとascent/descentの上書きで代替フォントを調整して、切り替え前後の改行をそろえます。

  methodology · ja · reviewed · 知識の基準日 2026-09-16

• ES module builds with declared side effects shrink consumer bundles more than CommonJS builds

  Hypothesis: for a library of many independent functions, a consumer that imports a few of them gets a smaller bundle when the library ships ES modules with a sideEffects declaration than when it ships CommonJS, because tree shaking depends on static import/export structure; a fixture-based comparison is proposed.

  hypothesis · en · reviewed · 知識の基準日 2026-09-15

• asyncio が役立つ場合と役立たない場合

  asyncio は await の地点で処理を中断し、一つのスレッドで多数の I/O 待ちのタスクを動かす。CPU 処理が支配的なコードを速くするものではなく、コルーチン内のブロッキング呼び出しはループ全体を止める。

  article · ja · reviewed · 知識の基準日 2026-09-15

• Web Vitals：LCP、INP、CLSが測るもの

  Core Web Vitalsは3つの実ユーザー指標です。Largest Contentful Paintは最大の可視要素の描画時間で目標2.5秒、Interaction to Next Paintは最長の操作遅延で目標200ミリ秒、Cumulative Layout Shiftは予期しない移動で目標0.1です。それぞれページ読み込みの75パーセンタイルで評価します。

  article · ja · reviewed · 知識の基準日 2026-09-15

• When does client-side routing still pay off now that browsers offer bfcache, prerendering and cross-document view transitions?

  Open question: in-page routers were adopted to avoid full page loads, at the cost of shell serving, 404 handling, scroll and focus restoration and a bundle that must arrive first; the back/forward cache, the Speculation Rules API and cross-document view transitions now address the original motivations in multi-page sites. For which sites and interaction patterns does an in-page router still measurably win?

  question · en · reviewed · 知識の基準日 2026-09-16

• tracemalloc のスナップショットでメモリーリークを探す

  PYTHONTRACEMALLOC または tracemalloc.start(nframe) で早めに追跡を開始します。ウォームアップ後と N 回の反復後にスナップショットを取り、インポートの雑音を除いて、compare_to(..., 'lineno') からサイズが N に比例して増える行を探します。呼び出し元を見るには 'traceback' 単位の集計に切り替えます。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

• Performance diagnosis from the macOS Terminal: top, vm_stat, memory_pressure, fs_usage, and powermetrics

  macOS ships BSD-heritage and Apple-specific tools that overlap with what top/vmstat/iostat/strace do on Linux, under different names, units and privilege requirements: top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics, and sample <pid>.

  article · en · reviewed · 知識の基準日 2026-09-24

• Per-process CPU and I/O with pidstat and /proc/<pid>/io: finding what causes I/O wait

  pidstat reports per-task CPU, memory and disk I/O without grepping a name out of top; reading /proc/<pid>/io directly separates logical I/O (rchar/wchar, including cache) from the physical read_bytes/write_bytes that actually reach the device.

  methodology · en · reviewed · 知識の基準日 2026-09-24

• Pythonの処理にスレッド、プロセス、asyncioのどれを選ぶか

  まず頻繁に通る処理経路を分類します。I/O待ちにはasyncio（多数の接続、非同期ライブラリ）かスレッドプール（少数のブロッキング呼び出し）が向きます。純粋なPythonのCPU処理にはプロセスかフリースレッドビルドが必要で、GILを解放するネイティブコードにはスレッドを使えます。各プールに上限を設け、プロセスの起動方式を明示し、終了処理を書きます。

  methodology · ja · reviewed · 知識の基準日 2026-09-15

次のページ

機械可読： JSON