Open mstormi opened 5 years ago
This appears is possibly as much about runtime performance as initial parsing?
Reported issue involving float
https://community.openhab.org/t/floating-point-operations-in-rules-causes-severe-performance-issues-on-hard-float-capable-hardware-software/63541
There's a performance problem with the DSL parser. After comparing lots of code samples, we believe it shows when we use code that is working with/casting primitives (Java value types) instead of Number types, i.e.
item.state.intValue
orvariable as integer
or the like. This happens to quite numerous people on the forum. I managed to reproduce it on a RPi3 running latest Zulu Java 8. I don't know if it can be reproduced on other processor/Java combinations. And since I still have rules files that - after eliminating that code in question - still take long to compile I'm inclined to believe that this is not the only problem instance. But at least it's reproducible so please try tackling that (by using a Java profiler ?).I believe it'll be easy to reproduce with code of your choice. I used the code below. The parser took 2.2 seconds on a RPI3: 2018-12-21 16:12:08.077 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Y.rules' 2018-12-21 16:12:10.289 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'Y.rules'
After I copied those last 3 lines 20 times (i.e. 60 occurences of integer casting), parser processing time jumped to 8.8 seconds.
2018-12-21 16:13:05.232 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'X.rules' 2018-12-21 16:13:14.075 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'X.rules'
I don't think that is normal and intended behavior but a parser bug. Under normal conditions, compiling common large rules files of 1k lines in size also just takes less than 10 seconds.
PS: just for reference, originally I opened this as https://github.com/openhab/openhab-core/issues/451