1 2 3 4 Previous Next 50 Replies Latest reply on Sep 8, 2015 3:35 AM by AllegroDataSolutions

    Is Everything Slower in version 14?

    AllegroDataSolutions

      I thought this was important enough to continue this discussion in a new thread. It concerns what I see happening when I open a solution built in FileMaker Advanced 13 and develop it further in version 14. It appears than any additions or modifications to the solution execute at less than half speed.

       

       

       

      Here's the example I used in the earlier thread:

       

      SelectDate.g is a global Date field, used to set the starting point for a number of calc fields and relationships used to filter records in various portals. In addition to a calendar popup to set the date, this solution has a number of buttons to increment the value of the existing date, which makes it easier for the user to make small changes to dates far in the past or future.

       

      The formulas for the buttons to set the starting date to the next month, previous month, next week, and previous week work instantaneously (the date changes as soon as the user clicks a button). This morning I added two more buttons to increment the starting date to the previous day or the next day -- but it seems to take forever for the date to change -- longer than 2 seconds -- which is enough time for users to think it isn't working and click on the button again, one or more times (making the operation take longer and end up on the wrong date).

       

      I am at a loss as to why a formula like this

       

           Set Field [SelectDate.g; SelectDate.g +1]

       

      should take so much longer to calculate than one like this

       

           Set Field [SelectDate.g; SelectDate.g +7]

       

      or even longer formulas, like this

        

           Case (  IsEmpty ( SelectDate.g ) or Day (SelectDate.g ) ≠ 1;Date (Month ( Get ( CurrentDate ) ) ;  "1" ; Year (Get ( CurrentDate )) ); Month ( SelectDate.g ) = 12;Date ( "1" ; "1" ; Year (SelectDate.g ) + 1); Date (Month (SelectDate.g ) + 1 ; "1" ; Year (SelectDate.g) ) )

       

       

      Pop Quiz: What's the difference between the formulas above?


      Answer: The first one was created in FMA 14. The other two were created in FMA 13 and opened in version 14. If I create a new version of the second or third formulas in FMA 14 it takes even longer to get a result than the first one. Worse, the slowest way to change the date of all is to select it from the calendar popup. The calendar just sits there (or it goes away and its outline remains for a while) taking several seconds to change the date. It's faster in every case to select the date value and manually type in the month, date, and year.

       

       

      I investigated further with this solution and found that the fields with drop down calendars that I placed on layouts using version 13 appear pretty much instantaneously. When I click on a date, the drop down calendar disappears immediately and the date value appears in the field simultaneously. If I add a drop down calendar to any new field that I placed on a layout with version 14, it takes the drop down calendar a few seconds to appear and even longer for the date value to be entered into the field (long enough to make the user think that it might not be working).

       

      Until this issue is remedied, it's going to be a big incentive not to upgrade existing solutions to version 14 or later.

        • 1. Re: Is Everything Slower in version 14?
          taylorsharpe

          Actually, most things I have done in FM 14 I have found to be faster.  But I am interested in why this is happening for you.  Are you using a timing function like CurrentTimeUTCMilliseconds to test and what are those results.  Are these fields indexed?  Is this on server or locally hosted?  Did you test PSoS to see if it was giving the same result to see if maybe it is a client issue.  Did you just convert it and the indexes had not been built or something like that?

          • 2. Re: Is Everything Slower in version 14?
            ibrahim_bittar

            Not for me . I find it faster in most things a A LOT FASTER in other few.

            • 3. Re: Is Everything Slower in version 14?
              AllegroDataSolutions

              I should note, for this discussion, what was previously mentioned in the other: I am using Windows 7, 64-bit version. If you are using a Mac, you may not see this issue.

               

              Please also note that I previously stated that the speed of scripts and objects created in version 14 are the ones that are noticeably lagging. (The same element, referencing the same field(s), runs faster if it was created in version 13 and then opened in version 14.)

               

              And, finally, something as simple as using the drop down calendar on a date field takes unreasonably long to display and to execute when the user clicks on a date. I don't have to time it; the lag is so long that I can count it off in seconds.

              • 4. Re: Is Everything Slower in version 14?
                harlowtech

                What theme are you using on the layouts?

                • 5. Re: Is Everything Slower in version 14?
                  planteg

                  One thing's for sure is that version 13 is 32-bit, and you are comparing with version 14 64-bit. Everybody expects a 64-bit version to be faster than a 32-bit version, but that's not necessarily true. It will be if you can carry operations 64-bit at a time, but not if you work on 32-bit or 16-bit values packed in 64-bit words.

                   

                  Ibrahim and Taylor, are you comparing version 14 64-bit or 32-bit to version 13 ?

                   

                  Gilles Plante

                  • 6. Re: Is Everything Slower in version 14?
                    ibrahim_bittar

                    Hi Giles

                     

                    I'm comparing Mac FM13 with Mac FM14. I can't tell about Windows performance.

                    • 7. Re: Is Everything Slower in version 14?
                      HugoEspinosa

                      I have to agree with Ibrahim, the only thing I had to upgrade was to add more RAM memory to the Server.

                      One thing I applaud to FileMaker people is that FMServer 14 is very stable !

                      Best Regards

                      Hugo

                      • 8. Re: Is Everything Slower in version 14?
                        jormond

                        The only place I've seen this, is when I place objects on a layout that was originally created in 13 or earlier. When I've gone through and fixed the styles and saved everything up to the theme, everything worked fine.

                        • 9. Re: Is Everything Slower in version 14?
                          AllegroDataSolutions

                          It seems like some of you are saying objects created in a 32-bit version of FileMaker remain faster when opened in a 64-bit version, while the same type of objects referencing the same fields and having the same styles are consistently slower when created in the 64-bit version. I'm having a hard time understanding the logic of that. It would essentially mean that I should design everything in a 32-bit version, then run it in a 64-bit version.

                          • 10. Re: Is Everything Slower in version 14?
                            jormond

                            I haven't seen that to be the case. What I have seen is that the CSS in 14 is slightly different ( more efficient ). So when the CSS doesn't match, you get a locally stored override to the CSS in the theme. Making the update to the objects and pushing it up to the theme resaved the CSS so it was rendering from the theme classes instead of copying over a full set of it's own CSS.

                            • 11. Re: Is Everything Slower in version 14?
                              AllegroDataSolutions

                              Yes, that appears to be the case. It was a little hard for me to tell with this particular solution, since it is using a custom theme that I built in version 13, the time lag is so long and it actually affects the performance of scripts attached to an object (which I didn't think would be possible). What a headache it's going to be to find every object affected and create new styles for every one-off instance where I changed a color to improve the aesthetics or used italics for emphasis!

                               

                              So, what do I do in the future? Use FMP stock themes (which users tend to hate and are more alike than they are different)? Develop solutions at half my normal speed, making custom styles as I go, driving up the cost to my clients? Or do them all at the end and not get a reliable idea of the performance until the solutions is pretty much done?

                               

                              In principal, I see the wisdom of using CSS to simplify FMP in Web Direct. But, like so much of the last few releases of FMP, the execution leaves a lot to be desired. I get the feeling that I am using either a very poor page layout/HTML editor or a very buggy database. I'd rather they focused on making the data handling fast and stable (especially importing and exporting records, reporting, and querying -- which are still in the cyber dark ages) and replace the rest of it with a robust HTML5, CSS, and script editors. While I have no objection to making those tools easy to use, ease of use should not come at the expense of making the whole app sluggish and buggy -- or make it a chore to do something somewhat complex. I'll give one example. I'd replace the script workspace with a keystroke recorder and allow the code it creates to be edited in a text editor, where the user could add flow of control code. Sure, you can have pick lists of functions and field names. In a large, complicated solution, that would help even the most experienced developers and cut down on the possibility of errors. But the current arrangement always seems to be guessing wrong and getting in my way. The most important thing to me would be the ability to turn all that creative guessing off. With every release of FMP, I feel like I'm taking two steps forward and one step back. (And, in some cases, one step forward and two steps back.)

                              • 12. Re: Is Everything Slower in version 14?
                                johnnyb

                                allegro wrote:

                                 

                                So, what do I do in the future? Use FMP stock themes (which users tend to hate and are more alike than they are different)? Develop solutions at half my normal speed, making custom styles as I go, driving up the cost to my clients? Or do them all at the end and not get a reliable idea of the performance until the solutions is pretty much done?

                                Take a day or two to prepare your own theme, then use that. The whole point is not to have to develop solutions at anything less than normal speed and to avoid making custom styles as you go.

                                Clone one of the new themes, go through all the widgets and adjust to taste, save it to a file you can use as a template, and import the theme from your template into your projects. I can highly recommend this approach.

                                • 13. Re: Is Everything Slower in version 14?
                                  jormond

                                  It would be nice to be able to focus/list/highlight all of the objects that are carrying the localcss. Then you could multi-select and apply a style and move on.

                                   

                                  I've resorted to using BaseElements ( and sometimes 2empowerFM's Clipboard explorer ), so find objects that have a <localcss> tag. This still needs to be done layout by layout, but overall my dev time has gotten faster. Which is nice.

                                  • 14. Re: Is Everything Slower in version 14?
                                    siplus

                                    It would be interesting to see what happens if you duplicate a field defined in the v13 and change the formula.

                                     

                                    Is it slow, too, as if it were created in 14, or does it retain the speed of the v13 ?

                                    1 2 3 4 Previous Next