7 Replies Latest reply on Aug 8, 2012 11:06 AM by JCPython

    Optimizing Runtime Performance

    JCPython

      Title

      Optimizing Runtime Performance

      Post

      Hello,

      I been reading up on ways to optimize performance of a filemaker runtime, mostly all i found is whats said from http://www.24usoftware.com/ and mostly about filemaker server.

       

      I use fm Pro advanced 12, i created a runtime and its being used by several users not on any network or anything like that, just a standalone runtime.

       

      I hear unsorted fields can slow down performance speed, and I have A LOT! if it would be worth fixing this by making them sorted and using a script trigger on the fields to be evaluated, i will but im just not sure how to go about setting the script trigger to perform the evaluation.

       

      Most of my text fields are all indexed but not all, i was planning on going through and making them all indexed, are there any typoe of text fields that i shouldnt make indexed? or any other field types that should be indexed?

       

      I have many small icons in my header which is repeated over 30 different layouts, should these images be placed in a global container field and then have the related container fields placed in the headers to have less images actually inserted? not sure if thats how that works or not.

       

      I think i remember seeing something online about rounded fields can slow down performance and that setting the corner radius to 0 would help, anyone else know about that?

       

      is there anything else that could be done to help increase performance? I also plan to optimize my scripts to hopefully clean up and work a bit better.

      Thanks!

       

        • 1. Re: Optimizing Runtime Performance
          davidanders

          http://help.filemaker.com/app/answers/detail/a_id/5268/~/performance-optimization-of-filemaker-databases

          Performance Optimization of FileMaker Databases

          How Can I improve performance of my databases?

          Answer ID: 5268Last Updated: Oct 20, 2011 09:47 AM PDT

          Products
          • FileMaker Pro
          •    12.x
          •    11.x
          •    10.x
          •    9.x
          •    8.x
          •    7.x
          • FileMaker Pro Advanced
          •    12.x
          •    11.x
          •    10.x
          •    9.x
          •    8.x
          •    7.x
          • All other products

          ISSUE:
          How to optimize FileMaker Databases.

          RESOLUTION: 

          1. Index all fields that will be used for searching and sorting.  The indexing may cause slowness for the initial search, however once indexed, the information will be found faster the second time.
          2. Calculation fields should be stored whenever possible.  Unstored calculations calculate "on the fly" when needed, which is much slower.  Avoiding finds on unstored calculation fields or doing record level access calculations on large files, can prevent slowness in databases.
          3. Put Summary fields only on layouts where they are needed.  Doing a count or a total of a large found set of records can take a long time. So instead of placing these fields on your data entry layout, place them on a separate layout, such as a print layout.
          4. Minimize the use of bitmap graphics on your layouts.  Whenever possible, use vector-based draw objects on your layouts such as any object drawn with the built-in graphic tools in the Layout mode.  It also includes any non-bitmapped objects from drawing programs.  When you do use bitmapped objects, use objects that are 72 dpi and a minimum bit depth (for example, if your bitmap includes 255 or fewer colors, make the bitmap an 8-bit file rather than a 24- or 32-bit file).

          For more information on optimizing shared databases, please look at the following answer: 

          Optimizing Network Performance for Shared Databases

          • 2. Re: Optimizing Runtime Performance
            JCPython

            Thank you, yes i have read all that, but not sure how to evaluate my newly sorted calc fields by script triggers so i can eliminate unsorted fields, and there must be more i can do to optimize.

            • 3. Re: Optimizing Runtime Performance
              davidanders

              http://fmbench.com/

              Signup for newsletter and get free FM Bench Detective

              Your question lead me here, have signed up, downloaded, but not tested, yet.
              Version 1 was released February 2012
              Version 1.1 was released August 2012

               

              There is a group on LinkedIn called FileMaker-Optimizers
              http://www.linkedin.com/groups/FileMaker-Optimizers-4001870

              • 4. Re: Optimizing Runtime Performance
                philmodjunk

                I think you mean unstored calculation fields.

                Many calcualtion fields have to be unstored others have to be stored so that they can be indexed inorder for them to function correctly.

                For those that could be stored or unstored....

                Unstored evaluate each time a new record is loaded on a layout displaying that field. Generally, this does not create a noticeable performance hit unless it's an aggregrate function computing an aggregate value such as a sum, average, standard deviation, etc from a large set of related records.

                You can see a very noticeable performance hit when you specify an unindexed field (such as but not limited to unstored calculation fields) in a sort operation or as criteria when performing a find. The more records in the table being searched/sorted the bigger the "hit" from using a field in such manner. On the other hand, indexed fields require that the indexes for that field to be updated with each change to data in that field. If you update the data to a few fields manually, you aren't likely to see any delays. Use Replace Field Contents to update large numbers of records or import large numbers of records into your database and you can see noticeable increases in the time needed to complete the operation when indexing is enabled for the field being updated or for many fields in a table into which you are importing data. Stored calculations will also evaluate during import (I think) thus, they will produce a small "hit" during an import.

                Indexes also increase file size. The more indexed fields--especially text fields with indexing, in your tables, the larger a database file will be.

                Given how large current hard drives can be and how often you will search or sort a database compared to how often you import data or do block updates, I tend to lean in favor of stored calculations, but then leave it up to FileMaker to turn indexing on or off as needed as the database is used.

                Note: Here's one trick for using criteria in an unindexed field to perform a search that minimizes the "hit" from doing so:

                1) Perform a find specifying only criteria in indexed fields. You might, for example specify a date or range of dates for a search of an invoice table.

                2) Return to find mode and specify criteria in an unindexed field--such as the invoice total that might be an unstored calc using sum to sum up your line item cost fields in a related table. Then select constrain found set to constrain the found set produced from step 1.

                When searching tables with large numbers of records (say 100's of thousands), this two stage find will be orders of magnitude faster than entering find mode and specifying criteria in both indexed and unindexed fields all in a single find request.

                • 5. Re: Optimizing Runtime Performance
                  JCPython

                  Thanks Phil!

                   

                  This is a very helpful read!

                   

                  Given how large current hard drives can be and how often you will search or sort a database compared to how often you import data or do block updates, I tend to lean in favor of stored calculations, but then leave it up to FileMaker to turn indexing on or off as needed as the database is used.

                  What is a block update? and i think if your right about unstored calc fields not making such a huge hit on performance then it may just be easier to leave them unstored.

                  Do you know if there is any truth to the round radius corners causing much of a hit on the layouts? i use the onyx theme for all of my 60+ layouts that receive user interaction, and would gladly eliminate the rounded corners of all the fields if it would help.

                   

                  I also wonder about the vector based images, i dont know much about that kind of stuff, i been getting all my images for my database from iconfinder.com, not sure if they are vector based or not but i can search for vector icons on google and get lots of vector icons, but not sure if this is what is meant in the paragraph below...

                  Minimize the use of bitmap graphics on your layouts.  Whenever possible, use vector-based draw objects on your layouts such as any object drawn with the built-in graphic tools in the Layout mode.  It also includes any non-bitmapped objects from drawing programs.  When you do use bitmapped objects, use objects that are 72 dpi and a minimum bit depth (for example, if your bitmap includes 255 or fewer colors, make the bitmap an 8-bit file rather than a 24- or 32-bit file).

                   

                   

                   

                  • 6. Re: Optimizing Runtime Performance
                    philmodjunk

                    A "block update" would be any action that modifies large "blocks" of records. Replace Field Contents is the obvious tool, but imports and looping scripts also qualify.

                    Don't know about the round corners. I hate the wasted space due to the excessive padding in FileMaker 12 themes so tend to switch to classic quite often just to go back to square corners and no excessive padding.

                    There are two ways, at the data level, that a computer can store data to be rendered into a graphical image. One method stores vectors plus some additional data about the regions defined by the vectors. (fill colors, textures, etc). The other (bitmapped method) stores a number for each and every pixel that makes up the image.Think of the difference as either charting a series of equations like y=mx + b to draw your image or coloring in squares on a piece of graph paper to create it.

                    In general terms, a bitmapped image takes a lot more memory/hard drive space to store and cannot be scaled as smoothly or as much as a vectored image. Thus a vectored image will load more quickly than a bitmapped version of the same image in most cases. But the application that loads such vectored image data must then be able to interpret the 'vectors' and draw the image. Thus, it isn't always the case that a vectored image will display more quickly than bitmapped. There are too many variables to make that a blanket statement. In much older versions of FileMaker, I found that if I used bitmapped images, downsampled to just the resolution of the monitor screen, they often loaded and displayed more quickly than a complex vectored version of the same image. I don't know if this would be true with current versions of FileMaker or not--but the above statement suggests that current versions of FileMaker may be much better at rendering vectored images than when I was testing this.

                    The bottom line, as in many cases when working with FileMaker is to experiment and see for yourself...

                    • 7. Re: Optimizing Runtime Performance
                      JCPython

                      ok i have a better understanding of block updating thank you

                      I agree also about the excessive padding on fields, i especially dont like how my fields need to height of 20pixels minimum to display text font of 10 properly.

                       

                      I will play around with the different image types and see if it can make much of a difference, i like using clean high res icons so hopefully i can keep using them.

                      Thanks so much!