How long does "get(CurrentDate)" take to calculate and is it worth using a variable instead? Answers: Not long, and probably not

I've wondered a few times if I'm overusing Get(CurrentDate). I mean I know things can't be cached, but sometimes we I have to use it and I've wondered if there's a break-even point where it makes more sense to put the date in a variable when a user starts up and use that instead.

I made a script which sets a variable to Get(CurrentDate) 2 million times, and then I created a second script which sets a variable $Today to Get(CurrentDate) and then set the other variable to $Today 2 million times and timed it.

The short answer is they took the same number of seconds, so I shouldn't stress this minutia. Test file attached in case anyone ever wants to verify.

temp.fmp12 (268 KB)

I once had to refactor and old app that was created around the time ver 6 was current. The current version was now 17. Since the beginning I was wondering why opening the app took so long. One day I decided it was time to investigate why it took so long. What I found stumbled me.

At some time a developer added to a table a calculation field that would store the value returned by Get(CurrentDate). What was the reason ? To compute the age of the individual for a record, and there were a lot of individuals. I don't recall all the details, but each time the app was started, all of these fields were updated :hot_face:, and that took a lot of time. I must add that I was working on a copy and that I had to start and top the app. The age was not correctly computed.

The way one use Get(CurrentDate) matters more than the function itself.

Yeah, makes sense. I have a bunch of students and we need to know if they've been reached out to today. Originally I just had a calc, but obviously it was slow. What I've done now is created a cache that runs every night at 1AM which resets that to 0 and then manually increment it if someone reaches out to a student.

I'm realizing now I might still have the original field from the prototype sitting in there. In other cases I have various calculations that were slowing down my list views (totaling credits earned by students, etc.) and my nightly script just looks at that calc field and copies it into a cache field for display. Is it possible/likely that those calc fields are slowing things down even when they're not displayed? I had assumed that since they're from related tables they wouldn't be indexed or cached and they wouldn't be a problem, but now I wonder...

Have you considered having a field “DateLastContacted” in your Student table?
Then, you can do a query for all records that do not have today’s date in that field.
Basically, put the comparison in the query, rather than putting the result of a comparison into a field.

1 Like