Test FileMaker Go 19 Performance

Dear all

I'd appreciate it if anyone with an iPad and FileMaker Go 19 installed could test the attached file. This all relates to: Claris Community (English)

If you read my post in the Clarid Community please ignore the references to running FileMaker Go on an M1 MacBook Pro, it is tangental to the iPad issues and unfortunately turned out to be a distraction to the main problem of the very poor performance I've obtained when testing FileMaker Go. The attached test file creates 500,000 records within the standard FileMaker Inventory template by selecting and running the New Record Test script.

WARNING - run this at a time you are not going to need the iPad in case you have similar results to my tests where completion has taken between 1 hour (2017 10.5" iPad Pro) and over 3 hours (2020 2nd generation iPad Pro 11"). For comparison using FileMaker Pro on a 2013 MacBook Pro with SSD drive took about 4 minutes and an M1 MacBook Pro under 2 minutes.

I suggest you ensure the iPad is connected to power and that the screen dimming is set to never for the test. The script reports the time taken at its conclusion.

I'd really appreciate the time taken, the iPad model and, if the results are wildly different to my results so far, any supporting details such as how you transferred the attached file to FileMaker Go.

Many, many thanks.

Andy

Inventory Test.fmp12 (236 KB)

Now running on an iPad Air 2, iPadOS 14.3, connected to power and screen lock turned off.

Duration: 03:11:59

Thanks Torsten, you are a hero.

I still can’t understand how my wife’s 3-year old iPad Pro was 3 times quicker than my 2nd generation iPad Pro 11” (although I still consider 1-hour unacceptably long) or why an M1 MacBook Pro/FMP19 has nearly 10,000% performance advantage over an A12 Bionic/FMG19 combination? (sorry lifted from my community post).

Yes I would expect the iPad to be slower, but considering we are constantly being told that iPads are faster than most laptops, I’d expect there to be an acceptable performance difference.

I’ve repeated the test a number of times on the 2nd gen and it is always takes over 3-hours and the MacBooks always complete the same test in minutes. Looks like I need to repeat the test on Val’s 10.5” iPad Pro and I’ve a 5th generation 9.7`’ iPad updating to IOS 14..3 to try that.

Mac Mini and MacBooks have fans that provide better cooling. May be linked to differences in heat dissipation. Just a guess.

I agree, but not by that margin.

What is the sense in creating 500000 records on an iPad?

Even when doing input from user, the usual performance is fine as the user is slow to press buttons and type.

Christian, first prize for asking this most frequent question when these type of subjects crop up.

Initially I was reporting on my first impressions using the M1 MacBook Pro with FileMaker Pro - My journey on the M1

Out of interest, this led to trying FileMaker Go on the M1 MacBook as a runtime alternative, which resulted in the test causing a repeatable system error that caused the whole MacBook to spontaneously restart. Due to this, I tried the same test on my iPad and it appeared to freeze the iPad, which is when I reported the problem within the Claris Community. After this, I discovered that the iPad wasn’t freezing, it was just soooo sloooowwwwww.

Most importantly, we have a rollout of a FileMaker Go project coming up that will require the receipt of JSON by the iPad via the FMS Data API, then later FM Go will need to create a larger amount of JSON and send it back in batches to the server. This will require some performance and I currently have concerns that FileMaker Go may not be up to it. However, we’re not in a position to test the actual system until we’ve progressed further with the project.

I guess my answer to your question is that this ‘accidental’ test has made me nervous about FM Go’s performance levels, which others have already reported within this forum. I’d like to gather enough data to continue to supply to Claris and I’d like to know whether this huge performance differential is due to the iPad hardware, IOS or FileMaker Go.

This is an interesting case.
I see you reported to Claris and maybe they can help.

Can you check if speed changes for 50, 500, 5000, 50000 or 500000 and is maybe linear?
Does it go slower over time?

And as I remember that FileMaker does some cleanup when script ends, what happens if you run a script to create 1000 records and trigger it with an On Timer action to run every second?

Christian, the test file I've posted here and on the community website has some script steps disabled, depending on which one is enabled there are options to create different record counts.

I've lifted this from the comments from the My journey on the M1 post:

I’m going to report this on the community website. I have gradually been reducing the number of records being created and even reducing the number to 100, results in the iPad Pro not completing the routine (I’ve left it for about 20 minutes) and will cause the system error and generate a full restart of the M1 MacBook Pro.

10 records works on both platforms. I’m not spending any more time on this trying to work out where, between 10 and a 100, it is failing.

It is important to emphasise that we know a lot more than we did when this was posted, but the test file can easily be changed to try to obtain the answers for the differing record counts. However, it will take a significant amount of time to run all the options.

James Tussey posted this within one of his replies to me:

However, the above assumes that the client is connected to the server. We intend to populate the FM Go app with JSON and use the new JavaScript features to present questionnaires using a web viewer, which will use the 'master' JSON to create questions, which are answered within the web viewer to update new JSON. It is this JSON containing the both questions and answers that will be consolidated and sent back via the Data API. Hence, the above link is not relevant to what we're doing as the FileMaker Go app is never actually connected to the server.