Handy little tip.
I posted my Hubitat log file into chatGPT and asked it to tally up the time spent in each function. I was not sure if it would work or not, but it did and I got this back.
Time spent in trace refreshUIafter: 09:22:51.145 - 09:22:49.204 = 1.941 seconds
Time spent in trace buttonLink: 09:22:50.996 - 09:22:50.273 = 0.723 seconds
Time spent in trace getHTMLSize: 09:22:50.264 - 09:22:50.262 = 0.002 seconds
Time spent in trace scrubHTML: 09:22:50.262 - 09:22:50.260 = 0.002 seconds
Time spent in trace extractValueBetweenStrings: 09:22:50.260 - 09:22:50.258 = 0.002 seconds
Time spent in trace compressHexColor: 09:22:50.258 - 09:22:50.257 = 0.001 seconds
Obvious where I need to focus for speed improvements.
...
1 Like
But can you believe it? 
It seems unlikely to me that it has developed the ability to exexute code in a Hubitat-like sandbox, and I don't even know if it can do that with vanilla Groovy or code of any kind, but I'd definitely be interested in how these numbers were computed (or if they were?) in any case. (All serious questions; I really don't know the answers.)
2 Likes
Probably @garyjmilne dumped timestamps at the beginning and at the end of the functions, and ChatGPT simply subtracted the two numbers? 
2 Likes
That's a lot more believable. 
(Not that it doesn't get basic arithmetic wrong sometimes too!)
1 Like
Yes, that is exactly correct. But in the log I pasted in most of those functions had multiple iterations so it is totaling up time spent in each function.
I found that the slowness was a call to a parent function that was getting executed each time through a loop. A little tweaking of that and I cut about 40% off my screen refresh time. Enough to go from noticeable to normal.
I did not take the time to figure out if the slowness was due to the call to the parent, or just the code itself. Anyone know if calls to the parent are inherently slower?
1 Like
Each call to the parent would have to wake that driver (or app) code to run, including things like reading (and writing) state every time it wakes (and sleeps), so I could see that being slower than something that is all in the same driver/app.
4 Likes
Yes,that is what I thought was probably the case. I shall have to do a little testing and figure out the overhead of a parent call vs an in app call.
The first scenario I tried was simply calling a function in both the parent and child that simply sent a message to the log. Differences were insignificant.
Second scenario was:
In the child app, call a function that returns a variable from the parent state.
In the child app, read a variable from the child state.
Repeat for each.
Results in milliseconds:
Parent 1st call: 76
Child 1st call: 14
Parent 2nd call: 73
Child 2nd call: 4
Third scenario was:
In the child app, call a function that returns a variable from the parent state.
In the child app, call a function that returns a variable from the child state.
Repeat for each.
Results in milliseconds:
Parent 1st call: 81
Child 1st call: 29
Parent 2nd call: 76
Child 2nd call: 4
Conclusions: There is a pretty significant penalty calling the parent and excessive calls should be avoided where performance is a consideration.
I'm going to have a make a few changes as I pull a lot of data for selection boxes from the parent.
2 Likes
Made changes to my child app to eliminate most calls to parent and my screen refresh time went from 1.9 seconds to 0.45 seconds.
This simple code might be useful to others. I set the flag state.startRefresh to now() when the user clicks refresh. Then put these lines into the code at strategic locations with the appropriate text.
if (isLogAppPerformance) log.info ("Start of Full Screen\Normal Section: " + (now() - state.startRefresh)/1000 + " seconds")
Now if I turn on performance logging I get a quick read on the overall screen refresh performance.
Start of Publishing Section: 0.45 seconds
Start of Display Table Section: 0.443 seconds
Start of Highlights Section: 0.437 seconds
Start of Design Table Section: 0.435 seconds
Start of Grid Layout Section: 0.426 seconds
Start of Free Form Section: 0.253 seconds
Start of Device Group Section: 0.252 seconds
Start of Layout Mode Section: 0.25 seconds
Start of Full Screen\Normal Section: 0.247 seconds
Start of Main Page: 0.224 seconds
The user clicked refresh: 0.075 seconds
2 Likes
