I've read discussions on the performance impacts of the proliferation of tables, fields, records, relationships, etc....
What about layouts? Let's say I'm designing a solution where custom layouts might be necessary (in order to produce all sorts of custom PDFs- one layout for each PDF). I realize there may be a better way to tackle that situation using fewer layouts, but just, in theory, is there any degradation in performance as the # of layouts increases? Let's say any # up to 1,000 layouts.
I realize the file size increases, but can that or any other aspect of numerous layout impact things like start up speed or WAN speed in very noticeable ways (i.e. as opposed to .01 second increase in loading time)?
There are three aspects to this. The layout definition, the data load, and the rendering.
Your table context is often not optional (though virtual tables can be used to great effect to avoid a summary across millions of records).
The theme is optional, and so are many rendering options.
If you used the same theme for each of the PDF layouts, and you select a minimal theme (purpose built for those layouts), and you only use theme styling for layout objects, then the load from your thousand layouts will be minimised.
As with all things, each layout adds a certain amount of "weight." The layout definition itself is not a big deal but it adds up. The number of objects is the primary consideration for the size of the definition. Having said that, the amount and extent of customisation of each object is what really adds to the initial size of the layout definition. Everything time you modify the settings on a layout object, that change is recorded. By the time you have a hundred objects, each with a few changes, you have added many kilobytes to the layout. And if you have a thousand layouts, that becomes megabytes.
Apex theme is often criticised. We should pay close attention to the fact that the theme has very few definitions. I believe this was a deliberately decision by Claris. This makes it extremely light and is a perfect starting point for solutions that will run over the WAN and mobile apps.
Layout rendering can be really complex too. Flat colours and square corners are fast, gradients (especially a gradient this is not perfectly vertical) and round corners are slow. Portals can be slow because of the increased data load (and for the summary calcs), just as lists can be slow because of the increased data load. Calculations embedded into Conditional formatting rules, and "Hide Object When" rules can bog the layout rendering down.
This is great info thanks. I use one custom theme, and I never alter any styles. I guess my main concern is will a filemaker database (when hosted on AWS) seem slower to open, use, or close because it has 1,000 layouts, or do those layouts only come into play when they're actually accessed?
Layout descriptions may be one of the things that need to be loaded early but I don't have solid info for that. Exactly what gets downloaded on the first window open is something that someone else may be able to answer. The trend has been for them to deliver less at a time, sending what is needed when it is needed.
In your situation, try it out. If it doesn't work as a single file, then having separate files is a great way to manage this sort of issue. You could put all the PDF generation tools into a file that isn't opened directly by users. Send commands to it and get results from it via PSOS. That way the Information doesn't need to leave the server.