ピティナ開発者ブログ

全日本ピアノ指導者協会のIT担当者が気まぐれにつづる技術系中心のブログです


FileMakerのレイアウト表示速度をオブジェクトごとに比較検証_その1

はじめに

立冬ですね、Hiroyuki Noguchiです。

FileMaker(以下:FM)のレイアウトを表示する際の速度感って、意識されていますでしょうか?
個人でデータベース作ってる人はそれほど意識しないで、べたべたと沢山のオブジェクトを置いてしまっているのではないかなーと思います。
しかし、オブジェクトが増えれば増えるほど、FMのレイアウト表示は遅くなります、重くなります。
それに、数だけでなく、オブジェクトの種類によっても、速度は変わります。

今回の記事、「その1」では、まず、テキストオブジェクトまわりに集中してパフォーマンスの違いを見ることにします。

フィールドの中身を表示するやり方あれこれ

とあるフィールドの中身をレイアウトに表示する際に、何も考えなければ、そのままフィールドを設置するはずです。
ここでいきなりマージフィールドを無意識で使い出す人は、たぶん、この先を見る必要のない熟達者でしょう。

そう、フィールドの中身を表示するやり方は、何も、フィールド設置だけではありません。

といったやり方があります。
今日は、これらの表示方法において、速度に差異が生じるのかどうか、比較検証してみます。

準備とか前提とか

今回、どんなもんで検証するかというと、

  • 都道府県市区町村
  • 番地
  • 建物

という3つのテキストフィールドを持っていて、それら全部を一つのレイアウトに表示させるだけにします。

テーマは「トランキル」で、すべてそれに沿ったスタイルのみにします。
レイアウトのヘッダとかフッタとかボディとかは、最初に作られたままの状態にしておきます。

検証用に使うファイルのテーブル構造ですが、以下のような感じでシンプルに。

f:id:ptna_it:20161107183657p:plain

c_address は、検証用として、テキストフィールド3つ置くのと、合成した計算フィールド1つ置くのとで、どちらが速いか?というのを確かめるためです。
各フィールドには、それぞれ、

  • 東京都豊島区巣鴨
  • 1-15-1
  • 宮田ビル3F

という値を入れておきます。

検証方法について

以下の手順でスクリプトを組みます。

  • 該当のレイアウトへ切り替え
  • 時間計測開始
  • 繰り返し回数とイテレータの変数設定
  • ループ開始
  • イテレータ加算
  • ウィンドウ内容の再表示(←ここでキャッシュクリアしつつ再レンダリングをおこなう。この速度を計測する)
  • ループ終了
  • 時間計測終了

前回、前々回の以下それぞれにおいてとった検証は、繰り返し1,000回でしたが、今回、1,000回だとあまり有意な差が出ないので、5,000回にしてみました。

ptna.hateblo.jp

ptna.hateblo.jp

逆に言うと、そもそも、5,000回もレンダリング繰り返してやっと体感できるくらいの差しかない、といえばそれまでなのですが、塵も積もればで、そういう一つ一つの若干の差の積み重なりで、レイアウト全体が重くなるのです。

また、検証用のスクリプト実行は、一回限りだと確証が揺らぐので、複数回実行してだいたいこれくらいに収束するだろうという値をキャプチャしました。

通常フィールド3つ並べる

ではまず、以下のようなレイアウトを用意します。

f:id:ptna_it:20161107183701p:plain

で、用意したスクリプトを実行します。

f:id:ptna_it:20161107183638p:plain

24.7秒。これが一つの基準ですね。

「いやいや、ラベルを横に置いているじゃないか、オブジェクトの量が多いじゃないか」というツッコミが入りますね。
では、消します。

f:id:ptna_it:20161107183711p:plain

スクリプト実行。

f:id:ptna_it:20161107190220p:plain

21.8秒。ラベルが消えるだけで高速化!
無駄なラベルは消しましょう。

マージフィールド

お次は、マージフィールドです。

f:id:ptna_it:20161107183658p:plain

これは、1つのテキストオブジェクトに、3つのマージフィールドを置いています。
スクリプト実行。

f:id:ptna_it:20161108111724p:plain

20.2秒。やはり通常フィールドより速いですね。

マージ変数

次、マージ変数です。
マージ変数の場合は、少しスクリプトステップに追加が入りますね。

f:id:ptna_it:20161107183659p:plain

スクリプト実行。

f:id:ptna_it:20161107183633p:plain

20.3秒。マージフィールドより遅い!
スクリプトステップが多くなる分、致し方ないところか。

計算フィールド

では最後、計算フィールド(索引設定なし)です。

f:id:ptna_it:20161107183630p:plain

f:id:ptna_it:20161107183700p:plain

スクリプト実行。

f:id:ptna_it:20161107183636p:plain

19.9秒! 20秒を切りました。何回やっても20秒を切ります。
一番速いのは計算フィールドなんですね、実は。

ちなみに、と、気になったので、索引設定をつけてみます。
索引のデフォルト言語もUnicodeにしてみたり。

f:id:ptna_it:20161107183631p:plain

スクリプト実行。

f:id:ptna_it:20161108114225p:plain

20.1秒! あれ、遅くなった!
何度やっても、20秒を切ってくれません。
索引がついていて鈍足になるのでしょうか。

そうかー、と思いながら、もう一度、索引設定を消してから再実行してみたのですが……
そうしたら何と、今度は、索引設定なし+デフォルト言語:日本語でも、20秒を切らなくなりました。
何だそりゃ、どういうことだ……索引のリセットはもちろん済ませてあるのですが。
ちょっと謎が残ります。

まとめ

ということで、まとめです。

速度(秒) 速度順位
通常フィールド(ラベルあり) 24.7 5
通常フィールド(ラベルなし) 21.8 4
マージフィールド 20.2 2
マージ変数 20.3 3
計算フィールド 20.0 1

おおよそ妥当な結果が出たかな?と思います。

実際の実装状況では、いちいちレンダリング速度のために計算フィールドを増やしていくなんていうのは愚の骨頂なので、マージフィールドで対応していくのが無難なところ、ということですね。

レイアウトレコードのロード時に、グローバル変数の値をセットしてマージ変数として表示させる、というのも、特段の負荷なくいけるというのが分かりました。

次回予告

さて、引き続き「その2」では、テキスト関連以外の表示についても検証を進めていきます。
具体的には、一般に「重い」とされる、以下4つについて。

  • WEBビューア
  • ポータル
  • タブ
  • スライド

ではまた次回に。

(著: Hiroyuki Noguchi)
この記事は現在0人が閲覧中