Lycolog

Node.jsとGoogle Chrome, Microsoft Edgeを用いて、try-catchとif文でエラー処理にかかる時間がどのくらい違うのかを調べた。

• 計測手法
• 計測結果
• 計測に使用したCPU
  • Intel Core i7 13700端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • Intel Core i7 1265U端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.58
  • AMD Ryzen 5 5600G端末
    • Node.js v16.20.2
    • Node.js v18.19.1
    • Node.js v20.11.1
    • Microsoft Edge 121.0.2277.128
    • Google Chrome 122.0.6261.57
• 全体サマリ表
• あとがき
• 参考

計測手法

次の4パターンを100万回実行した結果を記載している。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

確認に使用したコード：https://gist.github.com/Lycolia/304bc9e825e821c2d582f3ef9f700817

計測結果

CPUによって処理速度がかなり変動するが、いずれの環境でも処理速度の速さは以下の通り。

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. エラーオブジェクトをthrowし、try-catchで判定する方式
3. Result型としてエラーインスタンスをreturnし、if文で判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

計測に使用したCPU

Intel Core i7 13700端末

16C24T, 5.20GHz, L2 24.00MB, L3 30.00MB。ミドルタワーPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

Intel Core i7 1265U端末

10C12T, 4.80GHz, L2 6.50MB, L3 12.00MB。ノートPC。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.58

処理環境

処理結果

AMD Ryzen 5 5600G端末

6C12T, 3.90GHz, L2 3.00MB, L3 16.00MB。ミニタワーPC。

この端末はOSがUbuntuであるため、これまでのWindows環境との単純比較はできない。

Node.js v16.20.2

処理環境

処理結果

Node.js v18.19.1

処理環境

処理結果

Node.js v20.11.1

処理環境

処理結果

Microsoft Edge 121.0.2277.128

処理環境

処理結果

Google Chrome 122.0.6261.57

これだけバージョンが合わなかった。

処理環境

処理結果

全体サマリ表

凡例

1. Result型としてエラーオブジェクトをreturnし、if文で判定する方式
2. Result型としてエラーインスタンスをreturnし、if文で判定する方式
3. エラーオブジェクトをthrowし、try-catchで判定する方式
4. エラーインスタンスをthrowし、try-catchで判定する方式

CPUによってかなり差が出ているが、Intel CPUの13700と1265Uを比較した場合、例外を作らない1, 3のケースでは処理に大きな差がないが、例外を作る2, 4のケースでは有意な差が認められるので、モバイル向けとデスクトップ向けでCPUの処理効率に差があることがわかる。

AMD CPUと比較した場合、Node.js環境で例外を作らないケースではIntel CPUに大きく引けを取るが、ブラウザ上でのそれではパフォーマンスは高い。また例外を作るケースでもNode.js・ブラウザ共にIntel CPUと比較した場合のパフォーマンスが比較的よいという、面白い結果になっている。但しOSが違うことの影響もあるため、単純比較はできないが…。

あとがき

ひとまずtry-catchを使うと遅くなるということが確かめられたので良かったし、環境によって劇的遅くなるケースがあるというのは思わない収穫だった。

これを試そうと思った切欠はtry-catchが乱用されているコードを見てパフォーマンス劣化に繋がっているのではないかという疑問を抱いたからだ。try-catchでパフォーマンスの劣化が起きることは知識としても経験としても知っていたのだが、ちゃんとレポートしたことがなかったので今回まとめてみた。

try-catchの利用によりパフォーマンスの劣化が起きるというのは、古い時代にあった開発のお作法を知っている人であれば、それなりに常識だとは思うが、最近は知られていないか、知られていても意識していないことが少なくないと思われるので、今回記事にしてみた感じだ。

100万回の実行なので細かい話になるとは思うがパフォーマンスチューニングは細かいことの積み重ねでもあるので、むやみやたらに例外を使わないことは重要だと思う。そもそも例外は制御しづらいので、可能な限りif文で処理を書くことが望ましいだろう。

処理が遅延する原因としては二つあると考えていて、一つは例外生成時に顕著であることからスタックトレースの生成を初めとしたエラーオブジェクトの生成に時間がかかっているのと、もう一つはcatchでも遅延が出ることから、コールスタックから最寄りのcatchを辿るのに時間を取られていると思われる。今回の検証では特に出してないが、以前確認した時の記憶が確かであれば、catchに入らない限り、tryだけで顕著に処理が遅延することはなかったと思う。

あと、どうでもいいことだがconsole.log()で結果を出したときにEdgeだけObjectのKeyの順序が他と違ったので転記しているときに微妙に不便だった。何回やっても同じだったので恐らくEdgeだけキーをソートするアルゴリズムが違うのだと思う。まぁObjectとかHashとかMapとかDictionaryみたいなやつは順序が保証されないので別にいいっちゃいいんだけど、まさか実装によってソート方式が違うというのは思いもしなかった。

EdgeとChromeで処理結果が優位に違うのも、恐らくこれが原因なのだろう。分からないが多分JSのエンジンの実装が違う気がする。

それとLinuxのEdgeにはマウスジェスチャー機能がないという悲しいことも分かった。

参考

• Performance Effects of Exceptions in Java | Baeldung
• The Exceptional Performance of Lil' Exception

生のHTTPメッセージを見たい時に使える方法。devtoolsではフォーマットされたログしか見れないが、生のテキストを見たい時に使える。具体的には以下の画像のような奴だ。

よく忘れるのでメモとして残しておく

確認環境

やり方

chrome://net-internals/にアクセスするとログ収集ができるので、ログを集めたらイベントビューワで見ればよい。なおイベントビューワは外部サイトなので注意。

以前はブラウザ内で完結していて、リアルタイムに見れたはずだが、何故かできなくなっていた。

Edgeの場合はedge://net-internals/でもアクセスできるが、特にこだわりがなければ汎用性の高いchrome://net-internals/でよいと思う。

個人的に便利だと思うChrome拡張を書き出しておく。

Authenticator
よくあるQRコード式の2FAをするための拡張だ。TOTPであればなんでも使えると思う。たぶん
GitHubのリポジトリを見る感じMSの社員のコントリビュートが見られるほか、慶応義塾をはじめ様々な大手機関での採用が見られるので、不審なものではないと思われる。
態々モバイル端末を取り出して手入力せずに済むので非常に便利だが、同一端末で認証が可能になってしまう関係上、2FAの信頼性は揺らぐことになる。

Debug CSS
CSSのデバッグをするときに有用な拡張だ。以下の画像のように要素のサイズがどうなっているかなどを見れるので、要素が突き抜けている状態や、サイズが0になっているなどを確認するのに便利。

Resource Override
名前の通りリソースの上書きができる拡張機能だ。例えばサイト上にあるCSSやJSなどをすり替えることができる。
これはTamperMonkeyなどでは手を入れずらいようなことをする場合に便利だろう。

uBlock Origin
AdBlockの時代はもう終わった、そう思わさせる拡張機能だ。ほとんど大抵の広告をブロックできるので非常に便利である。ついでに不正なリダイレクトの確認機能もあった気がする。

Stylus
ユーザーCSSとして有名な拡張機能だ。任意のサイトのCSSを書き換えるときに重宝するだろう。例えばTwitterのセンシティブ表示外しといった用途は有名だと思うし、他にも様々なサイトで表示を自分好みにしたいときに便利なものだ。

GoFullPage - Full Page Screen Capture
ページのスクロールキャプチャを取るのに便利なやつだ。以前はChrome単体でもdevtoolsから出来たのだが確か五年ほど前にできなくなったので、こういったものを使うしかなくなった。

crxMouse Chrome™ Gestures
Chrome拡張でもっとも有名なマスジェスチャーの一つだろう。これがあれば自分の好きなマウスジェスチャを設定できるので非常に便利だろう。但し閉じたタブを開くなど一部動かないアクションがある。
因みに一般的なアクションパターンであればEdgeが標準でサポートしているので、そちらで事足りる場合はそれでもいいと思う。

参考までに以下はEdgeのジェスチャ設定画面だが、標準である程度一般的なパターンが登録されており、カスタムパターンを作りたい場合や、ここにないアクションを登録したい場合があると物足りない。

二次元画像詳細検索
この二次元画像の作者や出典は誰？と思って調べるときに有用なものだ。基本的に転載されたものやコラージュされたものを調べるために特化している。

Image Search Options
二次元画像詳細検索と用途がほぼ同じ拡張機能だが、海外で作成されたものでxbooru系やYandexなどへの拡張検索にも対応している。もちろん、二次元画像詳細検索へも問い合わせできる便利なものだ。二次元画像詳細検索と合わせて利用すると便利だろう。

EdgeとChromeは同じだったがNode.jsでは異なる挙動をしていたのでそのメモ

確認環境

環境別の確認結果

Edge

DevToolsで確認

const err = new Error('test');
Object.getPrototypeOf(err);

// {name: 'Error', message: '', constructor: ƒ, toString: ƒ}

Google Chrome

DevToolsで確認

const err = new Error('test');
Object.getPrototypeOf(err);

// {name: 'Error', message: '', constructor: ƒ, toString: ƒ}

Node.js

node -iで確認

const err = new Error('test');
Object.getPrototypeOf(err);

// {}

筆記具、調理具と続いた、この変革シリーズも第三弾になった。今回はGoogleからMicrosoftへという内容だ。因みに変革シリーズというのは記事のタグに変革と入れているところから名付けている。

私は長らくGoogle IMEとGoogle Chromeのユーザーであったが、これをMS-IMEとMicrosoft Edgeに変更したという内容だ。これもまた、レガシーへの回帰の一環といえるだろう。

まず何故変えようと思ったかだが、最大の契機はChromeのアップデートで使えない機能が毎回増えていく中、ある時UIが大改編されたことだ。

ブックマークバーやメニューの一項目が以前より巨大化し、この時かなり萎えて使う気がなくなってしまった（119.0.6045.160なら再現すると思う）。そして、これを機にIMEとブラウザをMSに戻そうと思ったのである。Edgeの方がまともだという根拠はなかったが、使ってみたところまともだったので良かった。

Edgeについて個人的に良いと感じたところは間違えてウィンドウを閉じてしまったときに、閉じたウィンドウを復元する機能があることだ。知りうる限りChromeにこの機能はない。他にもUIがChromeよりスマートで、タブを表示する部分に余計な物が出てこないことや、各種登録フォームで氏名が分割された入力欄にオートコンプリートがちゃんと入ることも評価している。

またカスタマイズ出来る項目が多く自分の手に馴染む内容にできることや、開いてるタブ一覧も垂直タブで見やすくできる部分は気に入っている。左に出て来たり、本来のタブバーが消えるのは気に入ってないが、これも{Ctrl} + {Shift} + {,}で切り替えられるので特に問題視してはいない。

Webサイトを右クリックしたときのメニューがやたら多い部分やお気に入りバーを展開したときの文字サイズがやたら大きい部分、ダウンロードのポップアップが若干扱いづらい部分は不満があるが、慣れれば気にならなくなると思うので許容範囲だ。

因みにスマートフォン（Android）のブラウザもChromeからEdgeに変更しているが、Secretモードと通常モードがタブになっていて見やすいことや、タブの一覧性の良さが気に入っている。メニューのカスタマイズもできるしお気に入りも見易い位置に置けるのはありがたい（Android Chromeのあれは存在を忘れてしまいがちだ…）。そのほかにスピードダイアルを編集できるのもすごくいいし、セキュリティが強固で、クレジットカードのオートコンプリートが3段階認証になっているのも好感が持てる。無駄な買い物をする前に思いとどまるチャンスが増やせるのはいい事だ。

基本的に私はGoogleを信頼していないので、Microsoftに移せる場所は移していきたいと思っている。例えばかつてはGoogle Docsを使っていたこともあったのが、MS Officeと比べるとチープなので随分前にOneDriveに移行している。しかしMSも万能ではないのでGoogleに委任して置かざるを得ない部分も少なからずあり、そこはGoogleを頼ることにしている。ただGoogleがしくじればMSに移行する準備はあるので、その日までといえばそうである。何故なら私がGoogleで使っているプロダクトは基本的にMS側にもあるからである。むしろ、その逆はないこともしばしばある。

IMEについてもGoogle IMEはカジュアルに使うには悪くないのだが、杓子定規に日本語を入力しようとすると上手くいかない。例えば「出刃包丁」を変換するときに「でばほうちょう」と打たないと変換できず、「でばぼうちょう」では変換できないと言うことが挙げられる。こんな打ち方をしていたら私の中であるべき日本語を忘れてしまう、日本人としてこれはいけないと思い、私はGoogle IMEを捨てることにした。

次使うIMEは連濁や促音化のような日本語を扱えるのが良いと思い、MS-IMEなら叶えてくれるのではないかと思ったところ、これが見事当たった。Microsoftは日本人のための開発をしてくれていると痛感したのだ。Google IMEは言っては悪いが片手間だ。ATOKと勝負しているようなプロダクトでは到底ない。

検索エンジンもGoogleからBingに変えようとしたのだが、これは失敗した。まぁ元々MSNを検索エンジンとして使っていたことがないので、これは穏当といえる。理由としてはBingは文字列を本来の意味で解釈した結果を検索結果として出してくるからである。つまりキーワード検索ではない。

例えばAmazonの欲しいものリストで本名がバレてしまうことについて調べたいと思い「干し芋 本名」で検索してみたところ、Googleは期待通りの結果を返してくれるが、Bingは食べ物の干し芋についての結果を返してくる。他にもBingは検索結果にAIの提案みたいなのが滲み出てきていて少々嫌というのもある（この結果もUserCSSでノイズをかなり消している）

Googleの検索結果	Bingの検索結果

Googleの検索結果はSEO業者やいかがでしたブログのような低湿な情報も多々あるのだが、個人的にはその辺りを回避する術を身に着けているため、余り問題になることがなく、検索エンジンまでは変えなくてもよいかと思ったのである。

ただGoogleはうちのブログをあんまりクロールしてくれないのでインデックスが遅いので、そこは全く評価していない。そこら辺のアフィサイトより確実に良質の記事を書いている自信はあるのだが…。いや、メモ書きがメインなので中身がスカスカの記事も多くあるし、そこは認めているが…。

インデックスについてはBingはかなり早く、翌週にはインデックスされていることもザラである。深く確認してないが仕組み的には翌日にでもインデックスされているかもしれない。反してGoogleは翌月でもインデックスされていないことがしばしばなので、ここについてはあまり評価していない。手動でインデックスリクエストすることもしばしばである。とはいえ、Bingも以前はうちのブログをインデックスしてくれなかったことがあり、その時は全く評価していなかった。MSにクレームを出してもインデックスされなかったのだが一年放置していたら何故かインデックスされていた。謎。

最後に余談だが、私の利用ブラウザの変遷について振り返ってみたいと思う。といっても記憶の限りなので正確性は怪しいところだが、Microsoft Edgeより以前は記憶が確かであれば、Netscape Navigator→Internet Explorer→Slepnir 1.66→Sleipnir 2→Sleipnir 3→Firefox→Google Chromeという感じだ。IEは恐らく4-6辺りを使っていたのではないかと思うのだが、当時はバージョンを意識していなかったので不明だ。最初のブラウザがネスケなのは親のPCの標準ブラウザだったからである。Sleipnirが3で止まっているのは開発方針に疑問を感じたからだった気がする。Geckoエンジンのサポート終了でFirefoxに乗り換えたものの、UIや設定や複雑怪奇な上に拡張機能が競合してカオスすぎたのでシンプルだったChromeに移った記憶がある。

上記の他にも古い端末向けにレンダリングエンジンがPresto時代のOperaを使っていたり、比較検討用にLunascapeやSRWare Ironを使っていたこともあるし、Tor Browserも使ったこともある。仕事の都合でSafariを使う事もなくはないが、宗教上の理由もあり、滅多に使わない。Presto時代のOperaはIEが通用しなくなった時代にWindows XP世代の骨董品マシンでWebブラウズするのには省メモリで大変重宝した記憶がある。因みに私は2004年に発売されたVAIO PCG-FR77J/Bを2017年まで使い続けていたことがある。これはネトゲで3PCをするためのパーツとして使っていた。

話は反れるが過去に使っていた端末はこんな感じである。NEC PC-9801DX2→FMV-BIBLO NE/33→SONY VAIO PCG-FR77J/B→東芝 DYNABOOK 型番失念→ASUS X550VC→ツクモBTO→自作PC