1 2 Previous Next 22 Replies Latest reply on Feb 8, 2016 11:54 AM by siplus

    Does FileMaker access a global variable faster than a record under all circumstances?

    FrankvanderMost

      When FileMaker needs to fetch the value of a global variable, it needs to look it up internally I imagine. This goes incredibly fast, so I imagine the question to be a no-brainer.

       

      On second thoughts, I imagine that if the list of global variables is beyond a certain length it might be faster to find a record in a small table. Is this the case, and if so, when would finding the record be faster? I'm thinking of finding a record through an ExecuteSQL function.

       

      cheers

       

      Frank

        • 1. Re: Does FileMaker access a global variable faster than a record under all circumstances?
          Steve Wright

          Since a variable is in memory, not being read from the disk / cache / network.. I would say that a variable would always be faster... but I have nothing to back that up, I have not tried to measure the difference, so its nothing more than an assumption.

           

          Of course, there's also the factor of that variable has to be set / maintained (if appropriate)

          • 2. Re: Does FileMaker access a global variable faster than a record under all circumstances?
            siplus

            Direct access to RAM will always be faster than interposing an instruction which has to be interpreted first.

            • 4. Re: Does FileMaker access a global variable faster than a record under all circumstances?
              wimdecorte

              Having a big set of global variables is considered a bit of a bad programming practice and it does carry risks, like Steve already mentioned: they do need to be maintained.

               

              Sone of the programming principles are explained here: http://www.soliantconsulting.com/blog/2014/02/all-variables-should-be-global-or-not

               

              If you need single values from any any context then ExecuteSQL() can be your best friend.  In my tests it is incredibly fast: 5-20ms for a simple query.  That's fast enough that I would not want to store much of anything in global variables if I can avoid it.

              • 5. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                FrankvanderMost

                Wim, thank you for that addition! I'm aware of the scope issues with variables and the bad practice of having too many variables, but your remark about the Execute SQL leads me to ask: have you also checked the speed of accessing a global variable? Is it faster or slower and how much?

                 

                Here is the background to the question. I need to prepare exports of about 150 to 200 fields in one table. For different exports the values may need conversion to something else. This something else will be based on calculations and on settings stored in different tables. The idea is that the user can select a set of conversion rules for a particular export. Selection of a set of rules will lead to the generation of a text ( let's call it calc_text ) for each field which will be run through an Evaluate function. (This way I don't need to hard-code a new set of rules into the definition of a calculation field each time the need for a new conversion arises)

                 

                So, during the export of one field, each record needs to access it's field-specific calc_text. I could store those in a table and use an ExecuteSQL to find the needed calc_text or I could generate a temporary set of global variables. If accessing a variable is a lot faster than an ExecuteSQL then I will go for 150 to 200 additional global variables (bad practice or not). If ExecuteSQL is faster then obviously, I would use a table to store the calc_texts.

                • 6. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                  wimdecorte

                  Frank van der Most wrote:

                   

                  Wim, thank you for that addition! I'm aware of the scope issues with variables and the bad practice of having too many variables, but your remark about the Execute SQL leads me to ask: have you also checked the speed of accessing a global variable? Is it faster or slower and how much?

                   

                   

                  I would imagine that reading a variable is going to be faster, no doubt about it.  Probably a fraction of a millisecond.  But in real life: the difference between say 4 or 5 ms vs. 0.5 ms is negligible and not noticable to the user.

                  (and I'm not talking about some code that would have to do 1,000,000 iterations, where the difference would be felt).

                   

                  Frank van der Most wrote:

                   

                  So, during the export of one field, each record needs to access it's field-specific calc_text. I could store those in a table and use an ExecuteSQL to find the needed calc_text or I could generate a temporary set of global variables. If accessing a variable is a lot faster than an ExecuteSQL then I will go for 150 to 200 additional global variables (bad practice or not). If ExecuteSQL is faster then obviously, I would use a table to store the calc_texts.

                   

                  I think variables are a good way to go here, but probably not global variables.. this is a scripted process so local variables will do just fine and will save you the cleanup at the end.

                   

                  I would probably want to do away with the calc field though and roll that logic into the script itself.  Easier to maintain code that way.

                  • 7. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                    FrankvanderMost

                    Thank you for your feedback, Wim. I'm not getting the scripting part though. Obviously preparing the variables, cleaning them up and so forth will take scripting, but the export ultimately is an export of fields, so how would you get rid of the calc field? I'm guessing you're thinking of ExecuteSQL. My users eventually need a spreadsheet and exporting to .xls also exports the field format. Is there a way to accomplish that with ExecuteSQL?

                    • 8. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                      beverly

                      I'll let Wim reply, of course, but what I always mean by "do away with the calc field" is to use scripted Set Field whenever possible. Set in variables, yes, but when you need to have values-in-fields for export, a calculation can often be replaced with Set Field. I've reduced time (i.e. bandwidth) for clients working remotely especially, by scripting so many things that used to be calculated. Even for large data sets.

                      beverly

                      • 9. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                        FrankvanderMost

                        Thanks for your suggestion, Beverly. I had not considered bandwidth: my university's network provides a tonne of it and the export will be within the LAN, but it will be different for future users outside the network. How do you go about multi-user issues here?

                        • 10. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                          beverly

                          Would your calculations be user-dependent in a way that Set Field would not work well? And if so, why? I'm just trying to tailor the answer to what works fasted within the necessary parameters.

                           

                          Remote users was my biggest consideration, so if there were user-dependant values, I had to work with global fields. But even at that, scripted rather than calculated was always much better.

                           

                          beverly

                          • 11. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                            FrankvanderMost

                            Sorry, I should have been more specific. Yes the calculations would be user dependent (remember that they can select a set of rules for each particular export) but I think I have that covered and a set field will obviously also take care of it. I am also buying that scripted will be faster than calculated. I meant what about the situation where two users try to export the same or an overlapping set of records with different calculations. If they use the same field for the Set field, then they would potentially get to export the other's value. Admittedly, in practice it may hardly ever happen depending on the application and its use, but I was just curious how you went about it.

                            • 12. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                              wimdecorte

                              Frank van der Most wrote:

                               

                              Thank you for your feedback, Wim. I'm not getting the scripting part though. Obviously preparing the variables, cleaning them up and so forth will take scripting, but the export ultimately is an export of fields, so how would you get rid of the calc field?

                               

                              Two different things and I probably rolled them into one.

                              First thing: the script that you would use to set the variables: make those variables local variables, not global ones.

                               

                              Second thing: the calc field: this one has nothing to do with the variables.  I personally like to keep as much of the code in scripts as I can.  A calc field has embedded code/business logic.  Meaning that I can't read a script and see everything that is happening because part of that is "hidden" in the field definition.  And once  you start having calc fields that depend on other calc fields then it really becomes difficult to troubleshoot.

                              So perhaps one option is to collect all the data based on the user's choices and dump that into a scratch table and export from there.  But perhaps it is not; I don't know enough about your solution to make that call.

                              • 13. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                                FrankvanderMost

                                Thank you for elaborating, Wim. I'm tempted to follow your advise but as you suggest, I have to think it through a bit more in light of other aspects of the solution. Your point about your preference for coding as much as you can in the scripts is very valuable! I never saw it as something that one can choose as a strategy or preference.

                                • 14. Re: Does FileMaker access a global variable faster than a record under all circumstances?
                                  siplus

                                  Setting a calc to a specific formula in Field Definitions is somehow a sui generis PSOS: you get the calc result already executed by the server.

                                  Setting it in a script does require the involved data to be sent to you by the server.

                                   

                                  I agree that having as much as possible in the script helps a lot when troubleshooting, but I do smell a speed penalty though.

                                  1 2 Previous Next