Optimize performance

[Matthew F]

While testing Filemaker Go on some databases hosted by FMServer I noticed some obvious performance issues. Drawing pages was pretty slow on complicated layouts, for example. However the most serious issue issue arose when performing a Find based on a calculated field. This brought the app to a near standstill, whereas it is reasonably fast on a desktop Mac. I assume that this is due to the processor performance of an iPad.

Is there a guide to designing databases which optimize performance for 'CPU challenged' clients that might be helpful for the iPad? It would be nice to know what sort of operations are handled by the client vs. the server.

[Vaughan]

IMHO the mobile platform is a game changer. The old concerns about RAM and CPU cycles will re-emerge (although they never really left for those who do embedded software, which is where we are now).

Restraint will be the new black. lol

In a way it's the same for those who have worked with FMP databases over slow networks: minimise everything, strip decoration out, display the very minimum necessary for the user to achieve their goal. And trust that FMI's engineers are caching everything as optimally as they can. :

I am working on a little system that displays images and have just changed it so 100 px thumbnails are generated and displayed especially for mobile users. They never see the bigger pics. I'm trying to only use native FM graphic elements too to minimise data transfer. I might drop this to 64 px if it's not snappy enough. My development platform is an iPod Touch.

There will be a compromise somewhere between time to download data and time to process it on the mobile unit: I'm not sure where that will land. As always, the introduction of better hardware (iPhone 4) will make all of this moot in weeks, months or years.

[Matthew F]

I am working on a little system that displays images and have just changed it so 100 px thumbnails are generated and displayed especially for mobile users.

Displaying thumbnail images is a good idea. If larger images are stored in a container, but not displayed on the mobile device, will performance suffer as the file gets too big? I'm wondering if FM loads an entire database into the client's RAM.

[Vaughan]

I'm wondering if FM loads an entire database into the client's RAM.

I'd say no because the amount of data possible is essentially infinite. Performance always suffers with size. It's up to the engineers to cache optimally.

I'm designing with the assumption that the databases are shared in FMS and accessed remotely on the mobile device, so actual database file size is not on my radar yet.

The database I'm working on offers the clients a desktop interface, a web interface (currently with IWP) and will have a mobile interface where appropriate. It's working out what's appropriate that's the hard part. I don't think a desktop interface on a mobile device will cut the mustard.

I think we'll have a new meaning for "context" soon. It will refer to where the client is and what device they are looking at, and their expectations. A client sitting at a desktop looking at FM Pro will have certain expectations about what they can and should be doing: a client looking at a web site remotely another expectation, and a client holding a mobile a third.

[El_Pablo]

How about using a presentation layer? Copying the interface on the iP[a|o]d would free up some bandwidth.