The red part took just on 60 secs to find 2 damaged ships.
The yellow part took about half that, circa 30 secs.
The green part took about the same time as the yellow.
The blue part took less than 1 second.
Is there any way Beanshell can be speeded up when evaluating the somewhat complex Expressions being used in GPIWs? Asking as, obviously, the regular expressions are obsolescent with Ver 4 looming in the future. When that happens a lot of stuff will be ‘broke’, for me as well as other module developers.
Would like a FO or similar to show that this has being, at least, perused.
To me and, I’m fairly certain, a bunch of other module developers, this time lag is damn well important.
Baring that, make sure you build into V4 similar expression resolution capability. V4 will be a bugbear otherwise.
The expressions not in blue were recreated post implementation of the blue so I, most likely, failed to correctly recreate them. Apologies for that. Further, they are Beanshell expressions so ‘||’ for OR is correct usage.
At the time of actual testing they were all correctly parsed and the expected results obtained. Incorrect expressions would have resulted in ‘no shows’, as in no result displayed.
Used single ‘=’ in lieu of ‘==’ because that’s how those expressions work.
I’m also remiss, in that I did not test the case of the CP actually implementing the whole expression and then just testing for findingstuff==“true”. That is 1 test I should have done. My bad.
I think I’ll try that and report back. Even though my expectation is that the legacy/regular expression is most likely the hands down winner in time used to display a result.
Then another shortfall with my post. I was looking for counters that have ‘used oil’, not damaged ones. Minor point only though.
Indeed, but the || I’m referring to are not logical OR—they are part of a regular expression. If || parses at all in a regular expression, it will be interepreted as an alternation operator |, followed by a zero-length alternative, followed by another alternation operator |—which will never in any circumstances be what you intend to match.
Also: Boolean expressions use short-circuit evaluation, which means they are evaluated from left to right and evaluation ceases once the value of the entire expression can be determined.
This means that for conjunctions, evaluation stops as soon as a false conjunct is found; for disjunctions, evaluation stops as soon as a true conjunct is found.
The consequence of this is that for best performance, you should order the conjuncts in your conjunctions so that other things being equal, the ones which are fastest to evaluate and most likely to be false are to the left. (Precisely, the order should be in decreasing probability of falsehood / execution time.)
Parameter for the GPIW being 'findingstuff==“true”.
2 oil usage counters found, I had deliberately moved 2 oil usage counters, so correct result. The process took 17 secs. A big improvement on a minute or 30 secs, but still not a patch on circa 1 sec for the entire legacy/regular expression result. Noting that the ‘findingstuff’ CP used a mix of regular and standard Beanshell. Also noting that I would then have to introduce yet another CP to several thousand counters. Got enough of those already, I do not need another 1 if I can avoid it.
The conjuncts which are string comparisons are good candidates for moving to the left, especially ones which will rarely be true. The regular expression I would make the last conjunct, a that’s likely to be the slowest to evaluate.
Additionally, your string comparisons are slower than they need to be in the true case—if you’re checking against "false", the comparison has to go all the way to the end when the value is "false", even though you know that the value will be "false" from the first character. Using "t" and "f" won’t be worse, and might be faster; using real booleans true and false instead of strings will surely be faster if BeanShell supports that.
