パフォーマンス確認の手順

アドオンプログラムを作成する際にぶち当たる壁がパフォーマンス問題であり、もし問題が見つかった場合は
大々的に改修を行わなければいけないケースも発生してくる。できるだけ早い段階で本番システム同等のデータ件数で
実行確認を行っておく事をお勧めする。

パフォーマンスに問題がある場合に確認するのが実行時間分析(トランザクションコード：SE30又はSAS)である。
プログラム名、又は、トランザクション名を入力して実行すると実行時間に関する詳細が分かる。
確認できる情報は、SQLの実行時間や各FORMでの実行時間である。FORMもなしにSTART-OF-SELECTIONに全ての処理を書いていると、どこでパフォーマンスが悪いのかを確認する事ができない為、ある程度処理を分割しておく方がよいだろう。

ここでは、大きくSQLに処理時間を使っているのか、それ以外かというのが把握できるのでそれぞれどのような対応ができるかを確認してみよう。

SQLの実行時間が長い！

・SELECT句では適切な項目のみ取得しているか。
ついついめんどくさいから*(アスタリスク)を使いたくなりますが、極力取得項目を記載しデータ転送量を減らしてみよう。

・キーやインデックスを指定してるのに遅い！
それ以外の項目もしてしてませんか？キーやインデックスだけで抽出し、内部テーブルに入れた後に削除する事でパフォーマンスが向上するか確認してみましょう。

・JOINして遅い! 単一のSQLだけど遅い!
どちらのケースも存在するので一概に言えませんが、JOINしてるSQLの場合はJOINを外してFOR ALL ENTRIESを使用してパフォーマンスが向上するか確認してみよう。
逆にJOINしていないSQLの場合は、JOINできるマスタがないかを確認してみよう。
選択項目からマスタを参照して、キーやインデックスでJOINする事ができる場合は有効だと思われる。

・インデックスの作成
Note等でインデックスを張る事を推奨しているならば特に問題ないと思われるが、それ以外の場合はインデックスを張らずに対応できるかを先に確認してみよう。

それ以外の処理が長い!

多くの問題はLOOPに関わると思う。いくつかのポイントを確認してみよう。
・LOOPしているデータ件数は適切か？
無駄なデータで処理を行っていないか確認してみよう。最終的に削除されるようなデータであればLOOPする前に全て削除しておこう。

・LOOP内でSELCT文を書いていないか。
LOOPの前にSQLを実行し、予め内部テーブルに格納しておく事ができないか確認してみよう。

・READ TABLEやLOOPの回数を減らしてみよう。
例えば、BSEGをLOOPしてBKPFからデータを取得する場合、同じデータを何回もとる事になるだろう。
そのような場合は、キーが変わった場合だけ取得する事ができないか等確認してみよう。

・READ TABLEを使用する場合はBINARY SEARCHを使用してみよう。又は、SORTED TABLEに変更してみよう。
参照する内部テーブルの件数が多い場合はBINARY SEARCHも有効です。

・フィールドシンボルを使用してみよう。
件数が多い場合は有効になることも・・・？