lame parser on number typecasts

[mstormi]

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 or variable 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.

var Timer waitTimer
var HSBType HSBvalue
var String redValue
var String greenValue
var String blueValue

rule "Licht manuell setzen"
when
        Item Testschalter received command
then
        hsbValue = EG_Wohnen_Decke.state as HSBType

        redValue = (hsbValue.red as integer).toString
        greenValue = (hsbValue.green as integer).toString
        blueValue = (hsbValue.blue as integer).toString
end

PS: just for reference, originally I opened this as openhab/openhab-core#451

[Rossko57]

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