Best Practice to speed up/optimize layouts

[Matthew R White]

I've been building my database for about 4 years now and its tricked out with portals and conditional formatting. The problem is its running extremely slow on all computers, when you click from one layout to another, theres about a 10 second waiting time before the layout switches.

I'm trying to go through each layout and do what I can to optimize or speed up the database. One thought I had is converting any (conditional formatting/Hide Object If) I had into a calculated field. Is this a generally good practice to have?

One example, I have a table within my main layout called Phone Log, you can add records, drag in files into container fields/etc. On the left I have 3 fields for each log, 1 field is the User entering the data, the second field is actually 3 different objects, a date entered field, a Yesterday Text and a Today Text. These are hide if (get current date <2) etc. (Not sure if these are slowing down the database. And the 3rd field is time entered.

I also have a plus button to add new records, currently all of my records are associated by the key field of Customer Number. When I click the add phone log button, filemaker copies the customer number within the current layout, goes to the Phone Log Table, Creates a new record, pastes the customer number then returns to the original layout. Works great but it takes about 5-6 seconds just to create a new layout. Is there a faster or better way to do this?

phone log.tiff

[Lee Smith]

Richard Carlton posted a free file on his site called RCC FileMaker Layout Optimizer that may help.

[LaRetta]

Hi Matthew,

Layout Optimizer focuses on non-style objects which is quite handy.  It is important to make sure all (or most) objects on your layouts use Styles and best to use only a single Theme so it is good to check.  I suspect that the majority of your slow-down results from basic design errors.

2 hours ago, Matthew R White said:

I'm trying to go through each layout and do what I can to optimize or speed up the database. One thought I had is converting any (conditional formatting/Hide Object If) I had into a calculated field. Is this a generally good practice to have?

No, calculation fields are a step down compared to Conditional formatting.  Conditional formatting CAN be overused but many things contribute to file slowness.  Portals can burden layouts and should be used sparingly - keep the number low.  Take advantage of sliders and popovers to keep data hidden until needed and move less-often viewed data to other layouts.

2 hours ago, Matthew R White said:

I have a table within my main layout called Phone Log, you can add records, drag in files into container fields/etc. On the left I have 3 fields for each log, 1 field is the User entering the data, the second field is actually 3 different objects, a date entered field, a Yesterday Text and a Today Text. These are hide if (get current date <2) etc. (Not sure if these are slowing down the database. And the 3rd field is time entered.

Not sure what you mean about 'the second field is actually 3 different objects' but the fact that three 'fields' hide if current date <2 is not a huge stress.

2 hours ago, Matthew R White said:

I also have a plus button to add new records, currently all of my records are associated by the key field of Customer Number. When I click the add phone log button, filemaker copies the customer number within the current layout, goes to the Phone Log Table, Creates a new record, pastes the customer number then returns to the original layout. Works great but it takes about 5-6 seconds just to create a new layout. Is there a faster or better way to do this?

There is nothing really wrong with this either but three things I would mention: 1) begin with a Freeze Window, 2) do not use copy but rather use Set Variable [ $customerNumber ; yourTable::CustomerNumber ] and 3) do not use paste and instead use Set Field [].

Some reason for slow-downs:

1. Poor structure
2. Over-using and/or improper calculations
3. Heavily burdening layouts with too many objects which must draw and/or fetch data particularly portals
4. Using portal filter on portals when child tables are large
5. Showing all records needlessly
6. Overusing conditional formatting
7. Large number of fields per table

I suggest you undergo a file review by an expert - find a professional you trust.  You may be able to hit-or-miss attempt fixing various things but really, it takes many years of experience to quickly identify the bottlenecks, what should be fixed first, and how to fix them.  An expert would be able to provide you a list of the major things causing you problems.  And then you can address them yourself as you wish, starting at the top of the list.

And no, I'm not attempting to drum business - I have my hands completely full.  You can provide an expert with your file, let them review it for 2 hours and then Skype with them for an hour and get an ear full.  3 hours of review would cost you $100-$150 per hour and save you several hundred hours of your time.  Do it yourself and you may or may not have succeeded in addressing the key issues.  I cannot stress enough the power of an expert's hands on your files - it is well worth the investment.

I wish you the best with your design.  

[Ocean West]

for fields that are not intended for data entry in browse or find you can use merge fields these tend to help optimize the layout, more so in list view. 

I would suggest you add a field in your table call it "CREATE" Make it a global text field. relate that field to the UID in the other table with allow creation turned on.  - then to create a record add to your script Set Field CREATE to Get( uuid )  then set any needed default fields (customer number) thru the relationship in the other table this relationship at this point is a 1:1 relationship - once you set al the needed fields clear the CREATE field breaking the relationship other relationships should resolve based on other keys. This negates the needs to leave the context of this layout and redraw elements from other layouts, or chance running layout triggers.