That’s so simple, well found !
I’m guessing adding an extra rule isn’t neccessary if you have some existing rule triggered on System started.
Any rule inside a rules files triggered compiles the whole file, whatever reason for firing there is.
What I have experienced, that sometimes when there is memory shortage the compiled rules are off-loaded. This is the case when e.g. you run Visual Studio Code on the same node.
My suggestion is that rules which have to be “rea-time” e.g. pushing button to get lights on, have to have an empty rule triggered by a cron, in order to have them always ready to run.
2 Likes
That’s another good find and workaround. Not something I’ve noticed myself, hosting on old desktop boxes with plenty of memory.
To summarize, increase the heap size to be as large as possible and then make sure you have a rule triggering in a file often enough that it never gets garbage collected and needs to be recompiled.
Correct?
I also like the idea of using a dummy OH instance for the LSP. Well, I wouldn’t say that I like it, it shouldn’t cause so much trouble on the main OH in the first place, but it is a clever work around.
@lukics, would you be willing to write up a tutorial on how to address these performance issues? There is lots of good stuff here but it might be hard to find in the future.
Sure,
I am new in contributing in that way. Need help in guiding me how should it be formatted and where located.
Put it in the Tutorials and Solutions section. The format can take whatever works best for you. You can browse through some of the existing tutorials for inspiration if you need it.
I tend to make my tutorials pretty formal (see the Design Pattern postings). Others can be quite informal. One person wrote their tutorial as a story (A State Machine Primer with HABlladin, the openHAB Genie) which I love!
Do what works best for you.
Thanks!
Be careful with this one. I tried this as a solution to slow rules execution and it made OpenHab start leaking memory and crashing regularly. My guess is some of the bindings (or maybe even the core) are relying on garbage collection in order to not leak memory.
Looks like this does not work anymore in OH3.
After migrating to OH3, the initial delay also doubled.
This puts my WAF at risk 
There should be a way to have rules precompiled after a reload.
Does it execute your rule at Startup and output the logInfo?
It would be bad if this workaround to precompile rules no longer worked in OH3.
Seeing as OH3 runs DSL rules under a completely different rule engine (that is also shared with other rule authoring systems), I can’t see any reason why execution delays, first-time or otherwise, would be related to any of this thread.
Nor any reason to think the old workarounds will be much use.
If you are experiencing performance issues with OH3, I would advise starting a new thread.