Assessing Performance

Who doesn't want their software to perform as efficiently and as quickly as possible. Don't we always want things to go faster and work better?

Of course we do. The problem is, we don't always take the time to fully think out what is happening when we solve a problem. Sometimes, we just robot our way through the code we are creating because it's how we've always done it - and it's easy or faster.

Being an "efficiency nut", when it comes to code, is something I really enjoy. It represents the fact that you have a reduced amount of code to accomplish the same thing that previously had more. Less code means less to maintain. Less code can also mean more performant.

In this video, I walk through a recent example of showing how a particular solution could be simplified. It's an example that plays out in the software world many times over. Most importantly, it represents what is the compounding effects of not taking the time to think out the most efficient solution. If and easiest to maintain, fastest performing solution is what you're after, then you may find a tip or two within this video about Assessing Performance.

Comments

Thank you for this informative video! Just wondering: I usually add some 'inspection' items to a layout, like a couple of fields that show information that is available to the developer only, but not to the users, for maintenance, support and trouble shooting purposes. I always add the 'hide object when' calculation to keep it out of the way for normal use. This is applied to certain keys, preference states etc.

The formula is evaluated multiple times, but is refers to a global field, like so:
= not ( menu::aa_debug )

When entering 'debug mode', I set the field 'menu::aa_debug' to 1, default is empty.

This doesn't add much overhead, does it?

It's probably not a huge impact on performance, but don't forget that you can have these values set in the "Watch" tab of the Data Viewer or (as mentioned in the video) you can place all the fields in a slide panel and just put the hide calculation on that.

My experience has been that a custom function evaluates once when the record loads and will only reload when a referenced field gets updated. An SQL query doesn't get triggered again unless it's referencing data from a field on the layout and that field gets changed. But the last time I tested that was in... v15, I think.

--
Daniel Farnan

Ignorance is curable, not preventable