Rule session factory compilation can take a long time

We’re using NRules in an interactive realtime application that needs to compile the rule factory on application start. We’re starting to notice that our rule factory compilation is taking a long time. (10 seconds and growing so far on my PC, and about 40 seconds on the low power device we’ll eventually be supporting.)

Specifically, this time is spent in RuleRepositoryExtensions.Compile() method.

Doing some initial profiling, the bulk of the time spent seems to be in RuleElementVisitor`1.Visit().

Drilling into this a bit, at first glance I see the bulk of the time spent in ExpressionComparer and LambdaCompiler methods.

A few screenshots of profiling are attached in case this is helpful.

[snikolayev]

@dadhi I just realized that you are the owner of the FEC project and so that’s why you were asking about the types of expressions others are trying to compile. TBH I personally haven’t had a ton of issues with the compilation performance, even using the built-in .net compiler, but clearly, it’s more painful for some folks. @larryPlayabl @kk738 I think this is a chance for you to share the types of expressions (types of expression nodes used) that you see causing the biggest impact on compilation performance, which could help @dadhi improve FEC performance, making everyone benefit from it. Also, if I’m not mistaken, FEC can fallback to .NET native expression compiler if it’s unable to handle some expression, which is another reason why you may not be seeing as dramatic a benefit as you might have expected. So, finding these cases where the fallback occurs, and reporting those to FEC project will also potentially benefit everyone.

@kk738 it was already pointed out by @larryPlayabl that normally, you would expect compilation to only happen once, at the application startup, and then you just keep ISessionFactory around and don’t really count rule compilation towards rules evaluation time. I find your idea of precompiling expressions interesting (and it has been raised before), so I might explore it. I was intrigued by the introduction of source generators in . NET, so perhaps that’s an option worth exploring. Regarding your point on using delegates instead of expressions in NRules - not possible, as delegates are opaque, and the engine needs to rewrite and stitch the expressions together to make it work in cases where expressions depend on other expressions.

[snikolayev]

As an option, consider https://github.com/NRules/NRules/wiki/Expression-Compiler to hook up FastExpressionCompiler that will improve the compilation performance.