記載されているように、オブジェクトやスクリプトの計算式ではCOUNT関数やIF関数の書き換え効果は大きいです。
他として、テーブル構成やファイルサイズによって効果の違いがあったり逆に低下するケースもありますが、QlikViewで効果があった内容を列記しておきます。
①ステートや変数を減らす
これは、ともに数が少ない時は気にせず利用している方が利便性のメリットの方が大きいですが、数が増えるとファイルオープンにかかる時間やリストボックスでの選択値の切替、クリアーなどにかかる時間がどんどん増加します。
QlikViewでは横思考に切り替わったV12からよりパフォーマンス低下の影響が大きくなりました。
(横思考が影響しているのかは不明ですが)
Qlik Senseもたしか横思考だったと思うので、同様のパフォーマンス低下があると思います。
ものによっては代用がきかないケースもあるかと思いますが、選択に利用する項目を、計算に利用するテーブルと連携していない別テーブルでも保持させる事で、ステートや変数をセット分析に変更する事が可能です。
ファイル内のテーブルやデータが増える事になり、ファイルサイズは大きくなりますが、対象データのテーブルに連携していないので、ファイルサイズ増加が直接パフォーマンスの低下につながることは、あまりないとおもいます。
②テーブルの正規化
基本的にQlikViewは正規化している方が処理が早いケースが多そうです。以前アーキテクチャーを読んだ際にも、そのように理解した記憶があります。ただ、ビューアーで見た際の見難さなどもあるので、1項目だけテーブルから分ける場合などは、効果と比較して総合的に判断した方が良いとおもいます。
③テキストデータの精製
前後や文中のスペースなどが不要であれば、Trim関数、PurgeChar関数などを利用して、スクリプト内で精製して取り込んだ方が良いです。また、日付情報のキーなどを数値やテキストのYYYYMMDDなどで保持する場合、AutoNumberを使わないのであればYYMMDDに変更するなど、出来るだけバイト数を少なく保持するように工夫した方がよいです。
④AutoNumber関数を使って、キー項目を書き換える
特にファイルサイズの圧縮効果は大きいです。デメリットとして、ロード時間が増加します。
計算速度が変わるかというと微妙ですが、バイト数は減るので、検索は早くなるのではないかと思います。
複数のキー項目に対して、全て単純にAutoNumber関数を使うと、変換対象となる全ての項目に対して、都度検索をかける(該当の値がAutoNumber化されているかどうか)ので、よりロード時間がかかってしまいますが、IDも合わせて記載する事で、かなり緩和されます。データ件数が多いほど追加されるデータ1件に対しての処理時間は少しずつ増加します。
（悪い例） AutoNumber(項目A) as 項目A
(良い例) AutoNumber(項目A,'idA') as 項目A
⑤圧縮率を変更する
計算処理とは別ですが、圧縮率を ' 高 ' で利用されている場合、 ' なし ' に変更すると、ファイルの保存や開閉(こちらは？)が早くなります。ファイルの保存時間はあきらかに違いが発生しますので、サイズの大きいファイルで開発、変更作業を頻繁にするのであれば、変更をおすすめします。ただ、バックアップファイルとして保存する際はサーバー領域確保のために圧縮したりと、場合によって工夫して下さい。私の場合、圧縮利用していた２G弱程度のファイルが４Gを超える事となりましたが、開発途中での保存時などのストレスがかなりなくなりました。また、以前はManagement Consoleで自動更新の際、たまに保存でのエラーが発生しておりましたが、圧縮をなくしてファイルサイズを大きくしたのにエラーはなくなりました。おそらく、圧縮を無くすことで、保存時の負荷は減っているのではないかと思います。
他にもいろいろあると思います。上記はそれぞれ概要で記載しましたが、詳しい情報が必要な場合は、また記載して下さい。
ただ、エンジンの仕様は当然わからないので、あくまでも今までの経験とそこからの憶測の範疇の話になってしまいますが....
では、チューニングがんばってください！
めんどくさい面もありますが、仮説がうまく結果に反映されると、少なくとも自己満足は出来ますので(^.^)
