- 投稿日:
Node.jsとGoogle Chrome, Microsoft Edgeを用いて、try-catchとif文でエラー処理にかかる時間がどのくらい違うのかを調べた。
計測手法
次の4パターンを100万回実行した結果を記載している。
- Result型としてエラーオブジェクトをreturnし、if文で判定する方式
- Result型としてエラーインスタンスをreturnし、if文で判定する方式
- エラーオブジェクトをthrowし、try-catchで判定する方式
- エラーインスタンスをthrowし、try-catchで判定する方式
確認に使用したコード:https://gist.github.com/Lycolia/304bc9e825e821c2d582f3ef9f700817
計測結果
CPUによって処理速度がかなり変動するが、いずれの環境でも処理速度の速さは以下の通り。
- Result型としてエラーオブジェクトをreturnし、if文で判定する方式
- エラーオブジェクトをthrowし、try-catchで判定する方式
- Result型としてエラーインスタンスをreturnし、if文で判定する方式
- エラーインスタンスをthrowし、try-catchで判定する方式
計測に使用したCPU
CPU | コア | スレッド | クロック | L2キャッシュ | L3キャッシュ |
---|---|---|---|---|---|
Intel Core i7 13700 | 16 | 24 | 5.20GHz | 24.00MB | 30.00MB |
Intel Core i7 1265U | 10 | 12 | 4.80GHz | 6.50MB | 12.00MB |
AMD Ryzen 5 5600G | 6 | 12 | 3.90GHz | 3.00MB | 16.00MB |
Intel Core i7 13700端末
16C24T, 5.20GHz, L2 24.00MB, L3 30.00MB。ミドルタワーPC。
Node.js v16.20.2
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 13700 |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 802 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 5,942 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 1,847 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 6,527 |
Node.js v18.19.1
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 13700 |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 887 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 5,826 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 2,006 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 6,464 |
Node.js v20.11.1
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 13700 |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 720 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 5,375 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 1,690 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 5,978 |
Microsoft Edge 121.0.2277.128
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 13700 |
OS | Windows 11 Pro 22H2(22621.3155) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 4,246 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 12,329 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 11,985 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 14,105 |
Google Chrome 122.0.6261.58
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 13700 |
OS | Windows 11 Pro 22H2(22621.3155) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 3,507 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 10,793 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 10,482 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 12,452 |
Intel Core i7 1265U端末
10C12T, 4.80GHz, L2 6.50MB, L3 12.00MB。ノートPC。
Node.js v16.20.2
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 1265U |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 972 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 11,416 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 2,288 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 13,993 |
Node.js v18.19.1
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 1265U |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 1,102 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 11,333 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 2,441 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 12,827 |
Node.js v20.11.1
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 1265U |
OS | Ubuntu 20.04.6 LTS (WSL2) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 888 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 10,881 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 2,269 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 12,254 |
Microsoft Edge 121.0.2277.128
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 1265U |
OS | Windows 11 Pro 22H2(22621.3155) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 7,526 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 34,761 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 39,005 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 65,752 |
Google Chrome 122.0.6261.58
処理環境
Env | Ver |
---|---|
CPU | Intel Core i7 1265U |
OS | Windows 11 Pro 22H2(22621.3155) |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 6,303 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 16,460 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 17,979 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 23,378 |
AMD Ryzen 5 5600G端末
6C12T, 3.90GHz, L2 3.00MB, L3 16.00MB。ミニタワーPC。
この端末はOSがUbuntuであるため、これまでのWindows環境との単純比較はできない。
Node.js v16.20.2
処理環境
Env | Ver |
---|---|
CPU | AMD Ryzen 5 5600G |
OS | Ubuntu 22.04.3 LTS |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 1,786 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 11,242 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 3,880 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 12,716 |
Node.js v18.19.1
処理環境
Env | Ver |
---|---|
CPU | AMD Ryzen 5 5600G |
OS | Ubuntu 22.04.3 LTS |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 1,933 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 11,094 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 3,839 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 12,767 |
Node.js v20.11.1
処理環境
Env | Ver |
---|---|
CPU | AMD Ryzen 5 5600G |
OS | Ubuntu 22.04.3 LTS |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 1,714 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 10,741 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 3,444 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 11,978 |
Microsoft Edge 121.0.2277.128
処理環境
Env | Ver |
---|---|
CPU | AMD Ryzen 5 5600G |
OS | Ubuntu 22.04.3 LTS |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 4,348 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 21,584 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 15,543 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 23,119 |
Google Chrome 122.0.6261.57
これだけバージョンが合わなかった。
処理環境
Env | Ver |
---|---|
CPU | AMD Ryzen 5 5600G |
OS | Ubuntu 22.04.3 LTS |
処理結果
処理方式 | 処理時間(ms) |
---|---|
Result型としてエラーオブジェクトをreturnし、if文で判定する方式 | 4,842 |
Result型としてエラーインスタンスをreturnし、if文で判定する方式 | 16,607 |
エラーオブジェクトをthrowし、try-catchで判定する方式 | 15,051 |
エラーインスタンスをthrowし、try-catchで判定する方式 | 18,095 |
全体サマリ表
凡例
- Result型としてエラーオブジェクトをreturnし、if文で判定する方式
- Result型としてエラーインスタンスをreturnし、if文で判定する方式
- エラーオブジェクトをthrowし、try-catchで判定する方式
- エラーインスタンスを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にはマウスジェスチャー機能がないという悲しいことも分かった。
参考
- 投稿日:
EdgeとChromeは同じだったがNode.jsでは異なる挙動をしていたのでそのメモ
確認環境
Env | ver |
---|---|
Microsoft Edge | 120.0.2210.9 |
Google Chrome | 120.0.6099.130 |
Node.js | 20.0.0 |
環境別の確認結果
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);
// {}
- 投稿日:
新しくセットアップしたTypeScriptのプロジェクトでauto-importが機能しなかったので原因を調べた。
ここ数年ちまちま起きて、そろそろイラついて我慢の限界を覚えたので…。
確認環境
Env | Ver |
---|---|
VSCode | 1.83.0 |
typescript | 4.8.4 |
再現方法
再現用のサンプルリポジトリでsrc/index.ts
の下図コードに対してauto-importが発動する操作を行う。
発生条件
恐らく以下を全て満たすときにauto-import操作をしようとした時に発生する。地味にややこしい。
node_modules
配下に存在し、@types/
モジュールを持たないものでかつ、同一プロジェクト内でimportされておらず、package.json
のdependencies
に書かれていない。
因みにhoge/piyo/fuga
のようなモジュールはhoge
だけがdependencies
にいてもauto-importが動かない。これを全部package.json
のdependencies
に書いていくのは目眩がするので正直auto-importを諦めて自分でimportを調べて書くのが無難だと思う。
発生原因
TypeScript 4.0で実装されたSmarter Auto-Importsのせい。
node_modules
をクロールすると重すぎるので@types/
だけ読み込んで、あとはpackage.json
のdependencies
も見るようにしたよという内容らしい。
解消方法
package.json
のdependencies
に全部のモジュールを書いていくというのが解決方法になるが、気が遠くなるので諦めた方がいい。初回だけは苦痛でもimportパスをどうにかして調べて手動で書いて、あとはauto-importされるのを期待するのが良いだろう(そんな何度もimportしないと思うが…)
取り敢えず基本npm i
で入れて行き、スラッシュ区切りのやつは諦めるくらいがちょうどいいだろう。
再現用のサンプルリポジトリではpackage.json
のdependencies
に"firebase/app": "^10.4.0"
を追加することでsrc/index.ts
のinitializeApp
に対しauto-importが発動する様になるはずだ。
あとがき
早い話、node_modules
配下にあって@types/
を持たないものはTypeScriptに対応する気がないんだな程度に思っておくのが良いだろうが、TS化で@types/
を廃止したライブラリがある当たり、すごく微妙な感じがある。ちょっとなんとかしてほしい。
そもそもpackage.json
のdependencies
はnpm packageを公開する時に動作するために必要な依存関係を登録する場所で、型の補助をする場所ではなかったはずだ。
少なくともnpmjsのdevDependenciesには以下の記述がある。つまりモジュールを配布する時に動作に不要な依存関係を含まないようにするためにdevDependencies
があるということだ。つまりdependencies
には動作に必要なものだけを入れるべきで、モジュールを配布しない場合、このフィールドは不要になるはずである。
If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use.
In this case, it's best to map these additional items in a devDependencies object.
ただTypeScriptがdependencies
に書かないとauto-importが失敗すると言っているので使うものはdependencies
に入れるというのが良いのだろう。(配布しないモジュールだとしても)
ただそれにしてもauto-importを動かすためだけに、dependencies
に同一モジュールのスラッシュ違いを大量に入れていくのはバカバカしいと思う。
"dependencies": {
"firebase": "^10.4.0",
"firebase/app": "^10.4.0",
"firebase/database": "^10.4.0",
"firebase/analytics": "^10.4.0",
...
}
かといってinitializeApp
がfirebase/app
にあるなんて知らんわけで、全部のパスに総当りしていくのも嫌だし、一々リファレンス漁るのも面倒だし、なんかもうちょっといい具合になって欲しい…。
- 投稿日:
Web開発をしていると取り敢えずHTTPリクエストが取れる雑なモックサーバーが欲しくなることがあるので、その作り方。
確認環境
Env | Ver |
---|---|
OS | Windows 11 Pro |
WSL2 | - |
Distoribution | Ubuntu 20.04.4 LTS |
PHP | 8.0.29 |
nginx | 1.18.0 |
作り方
- Windows側の
hosts
に127.0.0.1 mock-server.test
を追加 /etc/nginx/conf.d
に以下の設定ファイルを置く
server {
listen 80;
client_max_body_size 100m;
server_name mock-server.test;
access_log /var/log/nginx/mock-server.access.log;
error_log /var/log/nginx/mock-server.error.log;
location ~ ^/.*$ {
rewrite ^/.*$ / break;
# リクエストパスの確認用
proxy_set_header X-Request-Path $request_uri;
proxy_pass http://127.0.0.1:8888;
}
}
sudo service nginx restart
- モックサーバーのコードを書いて適当な場所に置く
<?php
$server_json = json_encode($_SERVER);
file_put_contents('log', "$server_json\n", FILE_APPEND);
php -S localhost:8888
http://localhost:8888/hoge
にアクセスしログファイルに追記されることを確認- おわり
おまけ
$_SERVER
の中身をフィルタしたい時
<?php
$ignoreKeys = [
'DOCUMENT_ROOT',
'REMOTE_ADDR',
'REMOTE_PORT',
'SERVER_SOFTWARE',
'SERVER_PROTOCOL',
'SERVER_NAME',
'SERVER_PORT',
'REQUEST_URI',
'SCRIPT_NAME',
'SCRIPT_FILENAME',
'PHP_SELF',
'HTTP_HOST',
'HTTP_CONNECTION',
'HTTP_UPGRADE_INSECURE_REQUESTS',
'HTTP_USER_AGENT',
'HTTP_ACCEPT',
'HTTP_ACCEPT_ENCODING',
'HTTP_ACCEPT_LANGUAGE',
'HTTP_CACHE_CONTROL',
'REQUEST_TIME_FLOAT',
'REQUEST_TIME'
];
$buff = array_filter($_SERVER, function($key) use($ignoreKeys) {
return !in_array($key, $ignoreKeys);
}, ARRAY_FILTER_USE_KEY);
$server_json = json_encode($buff);
file_put_contents('log', "$server_json\n", FILE_APPEND);
- 投稿日:
TypeScriptやJavaScriptだとコマンド一発で見れるコードカバレッジですが、C#.NETの開発ではちょっと手こずったので導入方法を記録しておく。
確認環境
Env | Ver |
---|---|
Visual Studio 2022 Community | Version 17.5.1 |
.NET Framework | 6.0 |
導入手順
- C#.NETで開発用のプロジェクトを作成
- 作成したプロジェクトのソリューションにxUnitテストプロジェクトを追加
- 何かしらの実装と、それに対するテスト実装を作成
- Fine Code CoverageをVisual Studioにインストール
- ソリューションエクスプローラからxUnitテストプロジェクトを右クリックしてテストの実行
- 下部トレイにあるFine Code Coverageタブを選択
- 表示されていない場合は表示 → その他のウィンドウ → Fine Code Coverageで表示出来る
- 表示されていない場合は表示 → その他のウィンドウ → Fine Code Coverageで表示出来る
- コードカバレッジが表示される
疑問
Visual Studio 2022にもなって標準でコードカバレッジも取れないの?
今どきそんな事あるか?思って調べてみたところ、どうやらEnterpriseであればコードカバレッジを取る機能がついている模様。
まぁ無料版だから仕方ないねということで諦めるしかないでしょう。Professional版にもないけど…w。VisualStudioの便利機能は以前から有料機能に組み込まれる傾向があるので仕方がない気もしますが、取り敢えず今回は有志が便利なツールを作っていてくれて助かりました。
因みにコードカバレッジ自体は無料版でも取れます。ただこれはXMLのカバレッジレポートを吐くだけなので、可視化するには別途ここからHTMLを生成する必要があり面倒なので、なんかもっと楽な方法はないかなと思って見つけたのが今回のFine Code Coverageでした。
しかしFine Code Coverage便利なのにそこまで利用されているように見えないのは、やはりテストに関心がある人が少ないのか、公式にあるカバレッジHTMLを吐く方法で納得しているのか、その辺りが気になりました。自前でFine Code Coverageの様な物を作っている人もいるでしょうが、それは少数派だと思いますし。
この方法で取れるカバレッジは正しいものか?
GitHubのREADMEを読む限り、組み込みのカバレッジレポーターのAPIを叩いて取ってきたものを表示しているだけに見えるので、恐らく正しいデータが出ているのではないかと思います。
少なくとも単純なコードのUnit testingを書いた感じではテストケースを増減することでカバレッジも連動して増減していたのと、組み込みのレポーターがそのくらいはやってくれている筈で、これはその内容を表示しているだけなので恐らく大丈夫なのではないかと考えています。