BCE を意識して Go のコードを高速化する
はじめに Go のコンパイラにはスライスや配列へのアクセス時に、インデックスが範囲内にあるかを実行時にチェックする仕組みがあります。いわゆる境界チェック (Bounds Check) です。この境界チェックは安全性の為に必要な物ですが、ループの中で何万回も実行されると無視できないオーバーヘッドになります。 Go のコンパイラは SSA (Static Single Assignment) の最適化パスの中で、境界チェックが不要と証明できたアクセスについてはチェックを除去します。これを BCE (Bounds Check Elimination) と呼びます。つまり、コンパイラが「このアクセスは絶対に範囲内だ」と証明できる様にコードを書けば、余分な境界チェックが消えて速くなるという訳です。 encoding/hex パッケージに対して、まさにこの BCE を活かした高速化の PR が提出され
GoのMySQLドライバは、なぜパラメータ数が増えるとPrepared Statementが急激に遅くなるのか？
こんにちは、株式会社 PKSHA Technology ソフトウェアエンジニアの中西です。 1. はじめに Go 言語で MySQL を利用する場合、標準ライブラリの database/sql と、ドライバである go-sql-driver/mysql を組み合わせるのが一般的です。この構成は、事実上のデファクトスタンダードとして定着しています。[1] また、セキュリティ対策も重要です。特に SQL インジェクションを防ぐため、プレースホルダ ? を用いた Prepared Statement の利用はベストプラクティスと言えます。[2] しかし、この標準的で安全な構成でも、パフォーマンスが著しく劣化するケースはあります。本稿では Prepared Statement の 2 方式を整理し、Go のデフォルト設定で性能が落ちる原因をベンチマーク結果と合わせて示します。解決策と採用時のトレー
Aurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違い - ANDPAD Tech Blog
こんにちは。アンドパッドでDBREを務めてます久保と申します。 こちらは ANDPAD Advent Calendar 2025 の24日目の記事です。 今日はAurora MySQLにおけるPerformance Schemaの手動管理と自動管理の違いについてお話しします。 背景 現在DBREではAurora MySQLのバージョンアップ（3.04.2→3.10.0）の準備をしています。 その準備の中で、開発環境のAurora MySQLのバージョンアップを実施しました。 その際に、バージョンアップを実施した一部のクラスターのFreeableMemoryが急激に落ち始める事象が発生しました。 そこで、performance_schema.memory_summary_global_by_event_nameテーブルで現在割り当てられているメモリーの集計サイズを確認したところ、バージョンア
「その処理、本当に並列ですか？」Node.js, Python, Ruby, Goで踏み抜くCPUバウンドの罠
この記事は「Hacobell Developers Advent Calendar」ー 8日目の記事です。 はじめに 「あの言語の並行処理って、結局どう動くんだっけ？」 日々の開発業務に追われる中で、ふと立ち止まってしまうことはありませんか？現代のアプリケーション開発において、マルチコアCPUの性能を最大限に引き出し、ユーザーに快適なレスポンスを返すために並行処理の理解は不可欠です。 しかし、使用する言語によって、そのアプローチや内部的な挙動は驚くほど異なります。 本記事では、Node.js, Python, Ruby, Goをピックアップし、それぞれの並行処理モデルが「CPUバウンドなタスク」と「I/Oバウンドなタスク」に対してどのように振る舞うのか、具体的なコード例を交えながらその違いを再整理します。 対象読者 本記事は以下のような方を想定しています。 複数の言語を日常的に使用している
速いRustコードを書きたい - 競プロ備忘録
競プロでは、どんなに非効率なコードを書いたとしても、要求された時間内に正しい答えが出せれば正義です。 なので、基本的には速いコードを書くことにそこまでこだわる必要はないです。 とは言っても速いコードを求めることは無意味ではなく、犯罪解法で計算量の悪いコードを押し通した結果、レートに直結することも稀にあります。 あとは単純に楽しいです。 AtCoderの過去問題やyosupo judgeのFastestを狙っているうちに、徐々に知見が溜まってきたので、思い出したものから雑多にメモしていきましょう。 より効率的なアルゴリズムを探す あたりまえですが、小手先の高速化よりもまずはこれです。 効率の悪いアルゴリズムを時間をかけて異常最適化するより、効率の良いアルゴリズムをサクッと書いたほうが圧倒的な高速化が達成できます。 調べられる限り最良のアルゴリズムを選択したが、なおもパフォーマンスに満足行かな
AuroraMySQL 負荷試験報告 〜結局のところスキーマ分離のDB設計ってどうなの？〜 その１ - MNTSQ Techブログ
はじめに スキーマ分離と行分離 目的と結論 目的 結論のサマリ 試験内容 試験環境とツール 負荷の設計 本番環境でのクエリ傾向の分析 QPSの測定 進め方 試験結果 スキーマ分離のボトルネック スキーマ数を固定して負荷をあげてみる 結果まとめ なんとか延命したい はじめに 弊社が採用しているDB設計は、テナントごとに独立したスキーマを持つ「スキーマ分離」 のデータ構造に基づいています。このアーキテクチャは、高いデータ分離性とセキュリティを確保できる一方で、「スキーマ数の増加に伴ってパフォーマンスが劣化する」という性質が指摘されます。 サービスのスケールにおいてこの「性能劣化」が、いつ、どのように顕在化するのかは、設計上の大きな課題でした。この漠然としたリスクを定量的に評価し、将来的な「行分離」アーキテクチャへの移行の是非を判断することを目的に、負荷試験を実施しました。 本記事では、この試験
VSCodeが重い！メモリ使用量を1/3にする設定まとめ - Qiita
重くなる主な原因 VSCodeが重くなる最も一般的な原因は、インストールされている拡張機能の数や質です。その他の原因として以下が挙げられます↓ 大規模なプロジェクトを開いていると、VSCodeが必要とするリソースが増加 ファイル監視プロセス（watcherService）がメモリやCPUを大量に消費 TypeScriptプロジェクトでの型チェックやインテリセンスの負荷 1. 拡張機能の最適化【最重要】 重い拡張機能を特定する コマンドパレット（Ctrl + Shift + P）から「Developer: Show Running Extensions」を実行すると、各拡張機能の起動時間を確認できます。
yoku0825さんがMySQLのインデックスの知見を語り倒す - Findy Media
MySQLのパフォーマンスを改善するうえで、「インデックス」は重要な要素の一つです。しかし、MySQLの内部でオプティマイザがどのようにインデックスを選択し、データを処理しているのかを正確に理解しているエンジニアは多くありません。どうすれば、インデックスを適切に使いこなせるのでしょうか。今回は、MySQL運用のスペシャリストとして知られるyoku0825さんに、インデックスの活用方法について解説していただきました。 B-treeインデックスの基本構造― 今回のインタビューでは、MySQLのインデックスの知見を詳細に伺っていきます。 インデックスを適切に活用するためには、その仕組みを理解することが重要です。そこでまずは、MySQLのInnoDBで最も基本となるB-treeインデックスの構造からお話しします。内部的にどのような構造になっているか、イメージを掴んでいきましょう。 今回は、MySQ
Why is Zod so slow? - LogRocket Blog
LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns. Zod is the undisputed king of TypeScript validation. In a remarkably short time, it has become the gold standard, celebrated across the ecosystem for its phenomenal developer experience, elegant chainable API, and robust type inference. For countless developers, Zod is not just a library — it
k8s-1m Overview
This is an effort to create a fully functional Kubernetes cluster with 1 million active nodes. Several years ago at OpenAI I helped author Scaling Kubernetes to 7500 Nodes which remains one of the CNCF’s most popular blog posts. Alibaba made a post about running Kubernetes clusters with 10K nodes. Google made a post about 15K nodes with Bayer Crop Science. Fast forward to today, GKE supports runni
PostgreSQL: 4億件のテーブルでSeq Scanが選ばれる問題を、統計情報(n_distinct)の改善で解決するまでのプロセス | フューチャー技術ブログ
PostgreSQL: 4億件のテーブルでSeq Scanが選ばれる問題を、統計情報(n_distinct)の改善で解決するまでのプロセス PostgreSQL18連載の5本目の記事です。 はじめにこんにちは、CSIG (Cyber Security Innovation Group) の市川です。 本記事では、私が現場で行った PostgreSQL のパフォーマンスチューニングについて、原因調査から解決までのプロセスを共有します。この記事が、「なぜか適切な実行計画が選ばれない、インデックスが使われない」といった同様の問題に直面している方の助けになれば幸いです。 また、今回の鍵となった n_distinct という統計情報の計算方法について、Appendix に考察を記載しているので、合わせてご一読ください。 (不適切な記載がある場合は、ご指摘いただけますと幸いです) まず本記事の要点とし
PostgreSQL 18の新機能「B-treeインデックスのスキップスキャン」 | フューチャー技術ブログ
PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ
AWS EC2接続：SSH踏み台 vs SSM性能比較 - AI活用で効率的に検証してみた
through-bastion /tmp/10mb_test_file Running iteration 1... Iteration 1: Latency = 1663 ms Running iteration 2... Iteration 2: Latency = 914 ms Running iteration 3... Iteration 3: Latency = 967 ms Running iteration 4... Iteration 4: Latency = 912 ms Running iteration 5... Iteration 5: Latency = 930 ms Running iteration 6... Iteration 6: Latency = 1015 ms Running iteration 7... Iteration 7: Latency
LLMの精度ってどう測るの？評価指標を調べてみた - SmartHR Tech Blog
こんにちは。AIアシスタントチームでプロダクトエンジニアをしているmizunaoです。 SmartHRでは先日、人事・労務に関する問い合わせにAIが回答するAIアシスタント機能をリリースしました。 この機能では裏側でLLM（大規模言語モデル）を利用していますが、開発にあたって「LLMの精度をどう評価するか？」という課題に直面しました。 実は私たちAIアシスタントチームでも、まだLLMの評価指標を体系的に活用できていない状況で、これから本格的に取り組んでいく必要があります。そこで今回、LLMの評価指標について調査・整理したので紹介します。 LLM評価指標とは？ LLMの出力を評価するには、人の目だけでは限界があります。そこで登場するのがLLM評価指標です。これは入力・出力・コンテキストといった情報をもとに評価器（Scorer）がスコアを算出し、そのスコアが一定の基準（閾値）を満たしているかど
大規模トラフィックを支えるGigaViewer for AppsのAPI負荷対策 - Hatena Developer Blog
こんにちは。iOS、Androidアプリエンジニアの id:tokizuoh です。『Inside GigaViewer for Apps』連載13回目は、Webアプリケーションエンジニアの id:magaming と一緒に出版社向けマンガビューワのアプリ版である「GigaViewer for Apps」（以下 GigaApps）における API での負荷対策についてお話しします。今回は、少年ジャンプ＋アプリ版のリプレイスにおける負荷対策の例をご紹介します。 背景 計測 負荷試験の目標設定とシナリオの定義 試験結果と課題 改善 データベース側の対策 大量のIN句の分割 取得するレコード数を絞る ElastiCache へのキャッシュ サーバー側の対策 DataLoaderの最適化 無料話をキャッシュ可能にする モバイルアプリ側の対策 クエリ分割 重複クエリの調査 リリース後の対応 雑誌発売
プロファイラを利用して Node.js サーバーのレスポンス時間を 200 秒 → 20 秒に短縮した話｜ogino
どんな問題を解決したのかこんにちは、ダイニーの ogino です。 ダイニーでは、飲食店向けのクラウド POS レジを開発しています。その機能の一つとして、一ヶ月分の売上などの情報を印刷できる「月締伝票」があります。 月締伝票のサンプル月締伝票に記載するデータは、Node.js バックエンドで集計をしています。この API はダイニーのバックエンド全体の中で最も重く、最近では一部店舗でレスポンスに 200 秒以上かかりタイムアウトエラーが発生していました。 その結果、月締伝票を発行することができないため顧客の業務に支障をきたし、複数の問い合わせが来ている状態でした。 プロファイラやログを手掛かりに調査したところ、ボトルネックを 2 行のコードだけに特定し、ほぼコストをかけずにレスポンス時間を 20 秒ほどに改善することができました。 改善リリース前後のレスポンス時間の変化ボトルネック 1:
Python 3.14、新型インタプリタ採用で実行速度が最大30％改善の見通し
今年（2025年）10月にリリースされる予定のPython 3.14では新型のインタプリタが採用され、実行速度が最大で30％改善される見通しであることが分かりました。 テイルコールに基づく新型インタプリタ 現在開発中のPythonの最新バージョン「Python 3.14」では、新型インタプリタが採用される予定です。 Python 3.14のドキュメント「A new type of interpreter」では、この新型インタプリタについて次のように説明されています。文中の「CPython」とはPythonの標準実装のことで、C言語で実装されているため通称CPythonと呼ばれています。 A new type of interpreter based on tail calls has been added to CPython. For certain newer compilers, t
CloudWatch provides execution plan capture for Aurora PostgreSQL - AWS
CloudWatch provides execution plan capture for Aurora PostgreSQL Amazon CloudWatch Database Insights now collects the query execution plans of top SQL queries running on Aurora PostgreSQL instances, and stores them over time. This feature helps you identify if a change in the query execution plan is the cause of performance degradation or a stalled query. Execution plan capture for Aurora PostgreS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
これって専門家から見てどうなんですか？ IIJに聞く「法人向けルーターと家庭用ルーターの違い」【イニシャルB】
HA構成のArgoCDパフォーマンス最適化への道 - CyberAgent SRG #ca_srg
