Curious performance issue when keyword matches potential variable

[nighthawk]

I built an expression library using Eval with about 50 operators (most of them taken from sample code – thanks a lot for that!) and noticed a curious drop in performance when defining a prefix function like not X and then having an expression like nothing == true where nothing could potentially be a variable. The performance drop is quite significant in my case, where by having adding that not prefix function slows down the overall evaluation by a factor of 5-6 compared to just having a ! prefix function.

I wonder if the evaluate method of the interpreter could be improved by introducing at the appropriate place a check that a function name shouldn't be evaluated against a substring. Though that might be done on purpose for some use case. In that case an alternative would be to provide a PatternOptions which allows telling the parser that this specific function keyword can't be a substring.

I can try to do those adjustments, though I'm not sure where to do them in the code. Any hints would be appreciated.

Some sample code which reproduces the slowdown (less than in my big library, but still by a factor of 3): https://gist.github.com/nighthawk/c7daa27285da406e5b2a71f8b789bf3f

[tevelee]

Thanks a lot for your feedback and detailed bug report! It’s a really interesting issue indeed, I’ll look into it as soon as possible

[nighthawk]

Great, thanks. The behaviour makes sense when thinking about a negation operator and doing something like !foo but would be good to disable this for word-only operators. Or maybe the parser can detect word boundaries so that it knows !foo can really be treated like ! foo.