1 2 Previous Next 29 Replies Latest reply on Jul 26, 2016 3:28 PM by codecruncher

    Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested

    rickenbacker360

      I have a 25-year old solution with 350+ layouts—most of which are quite complex. My solution will never win a FileMaker Design Award but my vertical industry has come to rely on it—even love it—for ease of use and feature set. My clients are not enamored of a tabbed interface (I've asked). The files were converted to fmp12 format using FMPA 13. All my layouts have the Classic Theme, which FM Tech support says is no longer supported.

       

      I just upgraded a client with 12 LAN network connections. There are no WAN connections, save something like remote desktop to an in-house (on site) machine. I do not support Web Publishing, WebDirect, ODBC/JDBC or SQL—strictly a FileMaker desktop solution. I've been getting "painfully slow" comments. One main layout takes 4–5 second to enter find mode when a user clicks a button with a single "Enter Find Mode" script step. That big kahuna Form View layout is around 2,000 px wide by 2,500 tall. Users tell me some finds on a 45,000 record data set take 40+ seconds to complete. 98% of my fields are stored; most are indexed. The layout does have a handful of unstored calcs. It also has a 27-row portal which never appears unless user scrolls to bottom of layout.

       

      Tech Support has advised me to downgrade to FMS 14 and FMP 14. This has not been tried yet, awaiting the weekend downtime.

       

      Tech Support thinks FMP 15's discontinued support for the Classic Theme is a significant issue. Of course, I have no real way of testing this premise. What they tell me is that I should employ the Minimalist Theme on my layouts. As you might guess, doing so by simply changing themes would be catastrophic. I figure it would take me several years to get the layouts working to the highest order possible. I'm willing to do less. (As one famous meme states: "Ain't no one got time for dat!") We've discussed and Tech Support affirms that—all things being equal—even with no changes to my local styles, I will see a performance increase.

       

      This is the method proposed by Tech Support and run by their Senior advisors. Unlock all layout objects; cut to clipboard, change empty layout to Minimalist Theme; enter browse mode to save layout changes; enter layout mode; paste clipboard contents; and finally, reset the tab order. Resetting tab order on the big kahuna takes 4 hours on a good day.

       

      The solution uses 17 files (it comes from the FileMaker IV (pre-FileMaker Pro days). In addition to a Menu file, there are probably 5 files containing the actual daily-use data. The other files are used for utility functions such as sharing/exchanging data between different clients with my solution (it's that kind of industry) and shortage of form letter clauses, phrases, etc. FTR, I have checked that all my external data sources use the relative path" file:FileName.fmp12". Tech support was big on this as a possible issue.

       

      QUESTIONS:

      1. I'm willing to do this, even though setting tab order can will be arduous. Does anyone have experience doing such a thing (Minimalist theme with all local styles)? Were the results positive? Could the users see a performance increase?

       

      2. I've thought about forcing a tabbed interface on my users. Tech support says such a layout will definitely draw faster. I'm unclear as to whether it will be, especially in light of recents posts regarding summary fields off to right of layout (not visible in normal screen sizes/resolutions) now automatically calculating even when the user does not display said summaries. FTR, I don't use sub-summaries on this big layout, but certainly have them on some of my list view layouts. In other development, I've used a posting script to populate global fields using a set field script step but that seem ludicrous. Any thoughts?

       

      3. I make extensive use of all the features offered to developers over the years, particularly conditional color. I'm very reluctant to tear down all that I've built these past decades, just to squeeze every last drop of performance our of my admittedly aging solution. I'm open to other performance ideas but not trying to be light speed. There are advantages to a visually informative interface over pure speed.

       

      4. Is that 27-row portal acting similar to the sub-summaries mentioned earlier, in that it is being drawn—even when user does not have it displayed onscreen?

       

      5. I have a user preference to use any desired zoom level. They are operating at 100%, meaning they are drawing way more objects than if they were to set zoom to 150%, for example. Would this be a good thing to advise?

       

      Thank you all.

        • 1. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
          ch0c0halic

          I suggest using FMP 15. It has a feature to not download portal records until the rest of the objects draw. Then it displays a progress circle while it downloads the related data for the portal.

          Also, FMP 15 keeps a local cache of data even over closing and reopening files. This can produce a huge speed increase, especially in static files, for example Zip code lookups.

           

           

          Classic is a very 'bad' performance theme. It doesn't really have a defined theme set. It uses whatever values are on the layout to build a set of CSS files to define the individual objects.

           

          For performance all items on a layout that are not using a standard theme setting should be saved into the Theme. I call this process 'flattening'. It flattens all changes to the theme back into a user defined theme. The reason this makes a difference is that the theme is only downloaded once to define all objects on the layout. Any change not added to the theme is sent in a separate CSS file. This could result in many extra files being sent in order to completely define the layout.

           

          Given the Classic theme is not even stored as a single theme you can see how it results in a very inefficient layout definition.

           

          The process of copying and pasting all objects on a layout has a 'cleanup' effect as well. An object with an 'undefined' or corrupted definition for the font will automatically have the theme's default font assigned.

           

          As was pointed out the drawback is you have to redefine the tab order. However, if you don't have to define every field you could remove the tab order and number the specific fields required to be at the beginning. Then you can allow FMP to auto assign the order of the remaining fields.

           

          Having the data in many files is about the same as having many tables. It's still related data and has to be downloaded separately.

           

          You can speed up the download by not showing related data or fields that use related data. A list layout should use only fields form the current Table.

           

          In Form views you can use tabs to speed up the initial window drawing. However, if you use even one calculation field that uses related data it will slow down. In order to use the related data FMP has to download all the related records. FMP does not download only the displayed fields of a record. So one field of a related table where there are 1000 related records requires downloading all fields for all 1000 related records. Hidden tabs don't draw so they don't need to download any data. You will see a delay in drawing the tab panel while FMP downloads the related data.

           

          You can also speed up displays of related data by sectioning the data into separate tables. For example you may not need all the postal and email addresses or phone numbers displayed at one time. For example: having phone numbers in a separate table with an intermediate table for selecting which one to display means only showing one "selection" record with three fields, primary key, selection, and foreign key. When you show the Tab for Phone numbers it draws only the one related record from the join table. Select Type Work as the selector and using in a multi-predicate join to phones it displays only one related record. IF you don't need to show every phone number the person has.

           

          Just because you have to scroll the window to see the portal does not mean the related data is not downloaded. Better to hide it inside a tab, which we know prevent data download.

           

          Calculation using related fields and summary fields are triggered to recalculate when they are displayed. So if they are not visible the related data is not downloaded. I think most users don't like to scroll the window. They would rather click something not he screen to display additional information. So again I suggest using a tab panel.

           

          QUESTIONS:

           

          1. I'm willing to do this, even though setting tab order can will be arduous. Does anyone have experience doing such a thing (Minimalist theme with all local styles)? Were the results positive? Could the users see a performance increase?

          Yes

           

           

          2. I've thought about forcing a tabbed interface on my users. Tech support says such a layout will definitely draw faster. I'm unclear as to whether it will be, especially in light of recents posts regarding summary fields off to right of layout (not visible in normal screen sizes/resolutions) now automatically calculating even when the user does not display said summaries. FTR, I don't use sub-summaries on this big layout, but certainly have them on some of my list view layouts. In other development, I've used a posting script to populate global fields using a set field script step but that seem ludicrous. Any thoughts?

          Tab panels have many advantages. Primarily not having to download data that isn't immediately, and may not be at all, needed. They also increase screen Realestate.

           

           

          3. I make extensive use of all the features offered to developers over the years, particularly conditional color. I'm very reluctant to tear down all that I've built these past decades, just to squeeze every last drop of performance our of my admittedly aging solution. I'm open to other performance ideas but not trying to be light speed. There are advantages to a visually informative interface over pure speed.

          I don't see a question in these statements. Color is great if it imparts immediate information. However, if the conditional formatting uses related fields to determine the color then maybe the speed reduction isn't worth it. I think it's a case-by-case decision.

           

           

          4. Is that 27-row portal acting similar to the sub-summaries mentioned earlier, in that it is being drawn—even when user does not have it displayed onscreen?

          See answer above

           

           

          5. I have a user preference to use any desired zoom level. They are operating at 100%, meaning they are drawing way more objects than if they were to set zoom to 150%, for example. Would this be a good thing to advise?

          Zoom level probably doesn't make any difference to performance. Unless, the computer's processor or display GPU is not up to handling the additional processing.

          • 2. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
            taylorsharpe

            You obviously need to a workaround to keep things going and going back to 14 or converting to a supported theme seem to be those options.  Going backwards is probably easier if you're just wanting to maintain. 

             

            If you've gotten 25 years out of this solution, that is great and probably fun to talk about.  But at this point, it probably is due for a major rework to take advantage of newer technologies, user interface, and strategies.  And this type of a rework is not something that will happen quickly and may even be a year long project with development and testing.  If this really is a major vertical solution, then this type of work will bring a lot of improvements. 

             

            One recommendation is that you seriously consider partnering with an experienced developer to help with development.  An experienced developer will have many ideas and suggestions learned from working on other solutions.  That plus your many years of knowing the business process can make for a great team to rework a solution. 

            • 3. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
              codecruncher

              It might be worth a try to convert your FM 11 file with FileMaker 12 instead of FileMaker 13. FileMaker 12 will convert the FM 11 file without specifying the classic theme or any other theme (a theme is never automatically selected). Your solution will be 'themeless' even in FileMaker 15.

               

              I have never selected a theme because it always slowed my solution down. Creating a new layout in a themeless solution in FM12 will automatically assign the default or classic theme to the new layout. However, copying an existing themeless layout to create a new layout will allow you to keep working without a theme (at least in FM 12).

               

              My solutions runs as fast in FM 15 as in does in FM 14 and FM 13. The latest update of FM 12.0.5 offered major speed improvements over earlier versions especially in regards to conditional formatting.

               

              It's an unconditional and unsupported solution but it works for me and it will only take 30 minutes of your time to see if it works for your file as well. Good luck!

              • 4. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                rickenbacker360

                Thank you for your thorough answer. I've had a whooping cough-like cold and not on my game. Sorry for the late response.

                 

                FileMaker Tech Support was very specific in my case. They want me back on 14. Perhaps that's because one of my clients using 14 is experiencing no problems. Granted, that client has only two network connections as opposed to my client with 12, using 15 who are experiencing the slowdown. Tech support was clear that they consider no real performance difference between 2 and 12 users.

                 

                The scope of a 25-year old solution is gargantuan. I've got 263,000 layout objects. Sadly, "flattening" is not gonna happen in my lifetime. I've only got a dozen clients using the solution (yeah, they do pay a lot each year to do so), but I could end up with 1000 or more styles and it will literally take years to implement the "right" solution—and then what? It really pisses me off that I've spent decades tweaking each layout to be just right, with layered fields and all the  best practices foisted on me by Claris/FileMaker over the years, only to have zero support for legacy issues. Classic was supposed to be some sort of "support" and now, it too is removed.

                 

                I don't want to rant...

                 

                I've been working on a tabbed layout structure which you indicate should make things faster. I intend to look closely at your other suggestions. Thanks again.

                • 5. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                  rickenbacker360

                  Thanks, Taylor. I've worked as an in-house developer with a FileMaker Partner for a number of years. I called their main guy the other day. Even they have not begun to touch the issue of themes in their flagship product.

                   

                  Respectfully, It's okay to have a best practices approach, but their solution and mine are simply too big. FileMaker, Inc. has their reasons for improving things, and If I were building from scratch, I'd use themes to the extreme, but the ROI of such a make-work endeavor is laughable (no disrespect to you).

                   

                  I am an experienced developer, but even if I had hundreds of thousands of development dollars to hire a developer to implement themes properly, that person would mess things up terribly. For example, how could they know that an array of layered fields visible to the user hides a bevy of masked fields in a layer to the back? And even if they did, would they get the formatting/style, correct?

                   

                  In terms of interface, this theme stuff is half baked as far as interface goes. Even if I name one theme, "Text_11pt_red" and another "Text_9pt_blue," Pretty soon I'd be naming "Text_9pt_Blue_Italic_Non_Printing_Small_Dialog_Use_xyzFile_PRintLayout_Only_OnWednesdays_BeforeNoon." Yeah, I'd use up 100 character names quickly and be confused myself as to which of the 1000 styles to use. Then on top of things, I'l probably pick the wrong style for something and it would inadvertently resize an object... on and on.

                   

                  No, this theme stuff is for new development and FMI has messed up by forcing it on us for legacy stuff.

                  • 6. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                    rickenbacker360

                    Darn! I wish I'd have known about converting fp7 using FMP 12. Seems way too late now. I've got 8 or 9 months of full-time development into the FMP 13 converted files. And guess what? That conversion broke all my mouse-over help. Seems some idiot at FMI decided to change how text in displayed mouse-over help displays. No big deal, just 7,500 iterations to fix! Took 2.5 months.

                     

                    Thank you anyway for what might have saved my bacon.

                    • 7. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                      rickenbacker360

                      codecruncher has an interesting observation about converting fp7 files in FMP 12. If I understand correctly, there is no theme attached to any such converted layout.

                       

                      Can anyone else corroborate his conversion method works? Can anyone likewise speak to performance being as good across 13, 14 and 15 for such "themeless" layouts.

                       

                      Will this work?

                      If I go back to FMP 11 version of my files and convert using FMP12, could I then cut all layout objects from my converted File A (leave the layout empty), and paste all layout objects from my FileMaker 13-converted File B (having Classic Theme)? Would the result be my File B Objects (complete with properly-fixed mouse-over help) and any new or changed objects, now residing on themeless layouts? (Yes, tab order needs to be reset.)

                      • 8. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                        rickenbacker360

                        Of course, even if codecruncher is correct and themeless layouts can be made (and used up through FMP15), I bet the day will come when going to FMP 16 or 17 will convert from fmp12 to fmp16 format—and we begin again with broken "features."

                        • 9. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                          beverly

                          I cannot confirm codecrunchers claim. However, I just updated a client from FM12 to FM15. Previously updated from fm pre-12. All layouts were "Classic". We only updated the layouts that needed to be published with Web Direct (250+ layouts). We chose Minimalist as the new theme, and previously the layouts had very little complexity, but there were issues on a few elements. We just converted themes, we did not go in and make a custom theme (yet).

                           

                          beverly

                          • 10. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                            codecruncher

                            A converted FileMaker 11 layout is identifies as 'classic theme' in FileMaker 13 or higher even if the classic theme has never been applied after conversion.

                             

                            Applying the classic theme to a converted FM 11 file in FileMaker 12 has the same detrimental effect on speed as selecting any other theme. After all the classic theme is a 'new FM 12 theme' in the style of FileMaker 11. If you have a custom layout it will change your design just like any other theme will. If, however, your file has no custom designed elements the layout will look the same as it did in FileMaker 11 even though new code will be added to the file.

                             

                            If the 'classic theme' has never been selected in FileMaker 12 and all newly added layouts have been created by copying existing layouts then the additional code of the new themes is never attached to the file. This behavior might have changed in FileMaker 13.

                             

                            I did all my conversions with FileMaker 12 and all my files open without further conversion in FM 13-15 which leads me to believe that the file is opened unchanged. This means that if a new theme has never been applied in FileMaker 12 it is not applied in FileMaker 13, 14 or 15. The layout is classified as a 'classic theme' but the new code of the FM 12 'classic theme' (or any other theme) has never been added to the file.

                            • 11. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                              beverly

                              what do you mean by "applied"? If you look in the layout, it's said to have the 'Classic' theme. How can it not be 'applied'? and what happens if this is changed to a WD-friendly theme for FM15?

                              beverly

                              • 12. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                                codecruncher

                                FileMaker does not specify whether the layout is a 'classic' layout with has no theme applied or a new FM 12 layout which has the 'classic theme' applied. They are both identified as 'classic theme' in FileMaker 13 or higher.

                                 

                                To apply the new 'classic theme' in FileMaker 12 open a FileMaker 11 file,  select the 'Layout' mode, go to the 'Layouts' menu and select 'change theme...'. Under 'Layout themes' select 'Classic' and press 'OK'. You now have a layout that was changed from a 'themeless' layout into a new FM 12 'classic theme' layout.

                                • 13. Re: Slow Performance, Classic Theme - FMP and FMS 15 - Advice Requested
                                  beverly

                                  Why would I change it to "Classic theme" for WD layouts?

                                   

                                  & can you point to documentation for 'classic' can be:

                                  converted older file

                                  or

                                  new layout with "Classic theme" applied

                                  ?

                                  1 2 Previous Next