|17|sp. FileMaker M1にネイティブ対応

|17|sp. FileMaker M1にネイティブ対応

FileMakerにとっては、毎年5月は恒例のアップグレード月間。親会社のAppleアプリは無料のアップグレードを続けているというのにまるで高額なサブスクのよう、愚痴ってみたくなります。
今年の5月はアップグレードなし、M1対応に手間取っているのかなと油断していたら、いつの間にか19.3でネイティブアプリになっていました。M1のMacに買い替えた時の投稿は19の体験版、20になったらアップグレードしようと思っていたのですが、慌てて19.3にアップグレードしました。
前回記事はこちら

体験版の頃はまだRosetta2で動いていたので、あらためてUniversalアプリのスピードを測ってみました。

KEN_ALL.csv郵便番号をインポート

KEN_ALL郵便番号をインポートして、かっこ付きの住所などを整形していくというもの。郵便番号簿は “|16| 使える郵便番号簿を自作する” で作ったものを使っています。

動画を見ても何をやっているのかよくわかりません。FileMakerはデータを表示させながらスクリプトを走らせると遅くなる傾向があるので、なるべく処理画面を見せないようにしているからです。レイアウトは必要なテーブルオカレンスを使っていますが、フィールドの配置は最低限にしてあります。

郵便番号簿から市町村リスト作成

都道府県のリストを作るのは簡単ですが、市町村リストを作るのは大変です。約12万レコードある郵便番号簿を県名、市区町村名でソートしてループしていくというものです。
県名で先にソートするのは東京都府中市、広島県府中市と同じ市町村名があるためで、同一県内で同じ名称の市区町村はないと思っています。

KEN_ALL.csvでは政令指定都市など区がある場合は「〇〇市〇〇区」と表記され、町村名は「〇〇郡〇〇町」と表記されています。東京特別区以外の区は自治体ではありませんし、郡名も自治体ではありません。私は「市区町村」と表記し、自治体としての市町村を「市町村」と表記することにしています。インポートして整形する際に市と区、郡と町村を分割するようにしてあります。

スクリプト

スクリプトは市町村名の変数を設定し、ループしながら郵便番号簿の市町村名と照合して、変数と違っていたら市町村名リストのテーブルに新しいレコードを作成するというシンプルなものです。

このスクリプトでは2つのテーブルしか使っていませんし、レイアウト上にフィールドを配置する必要もないので何もない画面しか見えません。動いているのかいないのかも定かではないのでグローバルフィールドを配置し、ループした回数をカウントさせ、総レコード数に対して何パーセント処理したかを表示しています。この処理を省略すると幾らかは速くなるかもしれませんが、何もないのは味気ないので遊んでみました。

しかし、動画を見ても面白くとも何ともありませんねぇ。

比較まとめ

以前、投稿したIntelも含めて、そのスピードをキャプチャ無しの状態で比較します。

マシンは
MacBook Air Early2020(Intel) メモリー16GB
MacBook Air Late2020(M1) メモリー16GB

郵便番号簿インポート・整形

  • Intel   512秒 (キャプチャ時 870秒)
  • Rosetta 2 421秒
  • Universal 303秒

市町村名抽出リ・スト作成

  • Intel   494秒 (キャプチャ時 772秒)
  • Rosetta 2 421秒
  • Universal 315秒

全てのテストでFileMakerのCPU使用率が100%を超えることはほとんどなく、超えても102%程度です。これは演算の順番が大事なのでシングルコアでの計算になっているためで100%を超えた部分はストレージへの書き込みにしか使われていないためではないでしょうか。Excelでも同様の傾向で、ループ処理などで100%を超えることはほとんどありません。シングルコアのスコアがIntelのi7やi9と同程度のM1はこのようなOffice系ソフトで有利だと思います。

使用したマシンはGPUが7コアのタイプですが、スクリーンキャプチャのGPU使用率が15〜20%程度で推移していました。IntelのGPUでは100%近く使っていてキャプチャしている時はスクリプトの処理速度も遅くなっていたことを考えるとGPUもそこそこ余裕があると思います。M1ではキャプチャしても処理速度は変わりません。GPU使用率は1コアあたりではなく、全体での使用率のようです。