@groovy.transform.CompileStatic question

🚧 Developers Coding Questions
1

This might be a dead-end, but I'm experimenting with improving performance using the @groovy.transform.CompileStatic transformation and I have a question . . .

I'm finding I get a compile error when I have a command like

zwave.centralSceneV3.centralSceneSupportedGet()

The compiler indicates that "zwave" isn't recognized -- just curious, is there a "longer" name for these command - i.e., a fully qualified name (maybe something of the form hubitat.zwave.centralSceneV3..."). I want to see if I can get past this error.

Similarly, I note it can't handle something like device.displayName. Is there a more "complete" name for "device".

Thanks.

2 
new hubitat.zwave.commands.centralscenev3.CentralSceneSupportedReport()
1 Like
3

That didn't work for the @CompileStatic attempt.

But, as I had indicated, this was only an experiment so no big deal.

For anybody else following this thread, I was trying to improve performance by applying techniques #2 and #4 from this article: How to Make Groovy as Fast as Java

Some more info for those interested...

End result: I think I did get some performance gains after applying the performance techniques in the above-referenced article, my drivers seem faster. Dimmers (particularly those in larger groups where the drivers are called many times) seem to be responding much faster than before -- however, this could be one of those "mysteries" of z-wave (e.g., the network decided on different routing), or it could be real.

Some more details:
1. Using CompileStatic
I was able to apply the @groovy.transform.CompileStatic only to very simple functions. So, for example, a simple function that wraps a call to another function can be done as in the example ...

@groovy.transform.CompileStatic
void advancedZwaveSend(hubitat.zwave.Command cmd, Integer ep = null ) { 
	advancedZwaveSend(cmd:cmd, ep:ep)
}

But once you start using any of the more complex classes (hubitat.zwave.commands ...), the CompileStatic transform results in errors (I think it needs more "information" about the classes so there may be some kind of an "import" of something missing). In any case, trying to apply CompileStatic to more complex functions was a dead end.

2. Casting
As outlined in #4 in the above-referenced article, I think I got bigger performance improvements by using more specific casting. I.e., using an explicit Object type (Map, Integer, etc.) rather than the more vague "def". I'm guessing this results in much less "hunting" by the groovy runtime to find a matching method signature. So with that in mind, I removed "def" type definitions from all my code.

2 Likes