プログラムの見える化ってこと自体が
良く分かりませんが、
それで本当にバグが分かるんですか?
例えば「関数Aの実行時間はこのくらいで、そのあと関数Bが呼ばれて…」というように、頭の中でプログラムの動きをイメージされていると思います。
while (cnt > 0) {
if (*ptw == 0xfc) {
func_A();
func_B();
:
しかし、実際には「関数A」が思ったより時間がかかっていたり、「関数B」が呼ばれる前に、割り込みが入っていたらどうでしょう?
実際のプログラムの動きは、頭の中に描いているイメージと微妙にズレていることがあり、そこに「バグ」が潜んでいるかもしれません。
なるほど、理屈は分かりましたが、
そもそも見える化ってどんなものですか?
では、小さなプログラムを例に説明します。こんなプログラムがあるとします。
例えばこの程度のプログラムでも、パッと構造を理解するのは面倒ですよね。
でも、CodeRecorderで見える化すると…
このように、関数の呼び出し構造と、実行時間を直感的に見える化できます。
関数のコールスタックのイメージが、時系列に表示されるのですね。
でも、これが本当に役に立つのか実例を見せてもらえますか。
実際のプログラムを見える化してみると、このような表示になりました。
ところどころ間隔が広い謎の箇所があります。
これはこの関数に時間がかかっていることを示しています。
とりあえず見える化するだけで、このような違和感を発見することができます。
異常な部分を拡大ズームしてみるとsend_sio関数であることが判明しました。
この関数は、正常な場合「30ms」で実行されますが、異常な場合「500ms」もかかっています。(表示をマウスでクリックすれば関数の実行時間が表示されます。)
今回の場合、大きな問題とはならないのですが、パフォーマンスに影響することが懸念されます。
send_sio関数が遅い理由を「ここからデバッグ」機能を使って調べてみます。
この機能は実行記録のデータを使って、再現デバッグを可能にします。
グラフの異常ポイントを右クリックし、「ここからデバッグ」メニューで、Cソースの逆ステップ実行や変数値を再現し、繰り返しデバッグができます。
逆方向にソースをトレース(トレース・バック)して行くと、500msかかるケースではデータが読み出し可能になるまでの待ち時間が長いことが判明しました。
今までにない新しい形のデバッグが可能です
この例のように一見正常に動作していても、普通のデバッガでは気づかない問題はたくさんあります。こういった問題を解決するために、プログラムの見える化は有効な手段です。
確かにこういったバグをデバッガで見つけるのは難しいですね。
ステップ実行で追いかけていては一生、発見することはできませんね。
なるほど、「見える化の効果」
地味にあなどれないですね。
CodeRecorderは、品質アップやパフォーマンス改善も得意です。
詳しくは、下記ボタンより製品紹介ページをご覧ください。
CodeRecorderはデバッグだけではない、
ということが言いたいんですね。