Reference discussion here:
Which nested conditional statement will execute faster? - Module Design - Vassal (vassalengine.org)
Why does using a beanshell expression for a GPIW take so long to execute when compared to the legacy expression?
For example:
Beanshell - {CurrentMap==“World Maps”&&MaP==“France”&&Unit==“HQ”} takes 19 secs to display the result (for 2 on map HQ)
Legacy - CurrentMap=World Maps&&MaP=France&&Unit=HQ takes less than 1 sec to display the same result
Me, I’m going to opt for using the legacy expressions for the GPIWs I use. Why hang around for 19secs to get the result when less than 1 sec gets the same result.
Because beanshell is a general-purpose Java interpreter running in Java (a semi-interpreted language itself). The Legacy expressions are hand-coded in Java, so only running in 1 level of interpretation.
You are more than welcome to use the Legacy expressions,but be warned, where the Beanshell expressions are completely consistent and logical , the Legacy expressions are quirky and inconsistent, make assumptions about what the left and right hand side of each conditional are, do not support parentheses or &&/|| operator precedence properly and do not handle oddly named properties well or building up property names.
But if they work for you, go for it.
Thanks for that insight Brent. Thus far there have been no issues arising, but I have only run a few cases. As per usual, once I implement the changes and the new modules come into use with the WiF community, will there be a more thorough test. I will be very interested in how this goes. Hopefully, no issues.
Did you mean hand coded or should that be hard coded?
No, the code that handles the parsing and execution of Legacy expressions has been ‘hand-coded’ by Rodney back in pre-history, there is specific code in Vassal that does this. As opposed to Beanshell where any Beanshell expression is just pumped into the Beanshell black box and a value pops back.
If you get a legacy expression to work, it will keep working. You won’t have too many problems if you keep it simple as you have, combing conditionals and &&. Don’t expect anything more complex to make any sense.
Wow. Rodney was keen.
I did find that in rewriting the GPIW conditions that I had to be very careful. I just was not sure of what would work or not, so I had to experiment a little. The ‘fun’ part were those multi ORs and getting them to work. Some examples of the beanshell and the legacy follow:
HQ FIND:
{(CurrentMap=~“World Maps|AmericasCE|AmericasAiF”)&&(MaP=~“chinat|chicom”)&&Unit==“HQ”}
CurrentMap=~World Maps|AmericasCE|AmericasAiF&&MaP=~chinat|chicom&&Unit=HQ
{(CurrentMap=~“World Maps|AmericasCE|AmericasAiF”)&&MaP==“USA”&&Unit==“HQ”}
CurrentMap=~World Maps|AmericasCE|AmericasAiF&&MaP=USA&&Unit=HQ
Oil Usage:
{(CurrentMap=~“World Maps|Allied TFs”)&&Moved==“true”&&OilUse==“Yes”&&((Type=~“air|cvp”&&rebase_Level==1&&srebase_Level==1)||Type!~“air|cvp”)&&MaP=~“chinat|chicom”}
** {CurrentMap=~“World Maps|Allied TFs”)&&Moved==“true”&&OilUse==“Yes”&&rebase_Level==1&&srebase_Level==1&&MaP=~“chinat|chicom”} - With this version I decided to add 2 markers to some other prototypes thus enabling some simplification of the condition (added markers rebase/srebase_Level value 1 to non aircraft units)
CurrentMap=~World Maps|Allied TFs&&Moved=true&&OilUse=Yes&&rebase_Level=1&&srebase_Level=1&&MaP=~chinat|chicom
Locate Transports:
{(CurrentMap=~“World Maps|AmericasCE|AmericasAiF|Allied TFs”)&&(MaP=~“chinat|chicom”)&&Unit==“TPT”}
CurrentMap=~World Maps|AmericasCE|AmericasAiF|Allied TFs&&MaP=~chinat|chicom&&Unit=TPT
@Brent_Easton - accepting all you say and that beanshell (love it) comes with a performance cost, is there something extra going on here … perhaps, a bug in how this particular part of GPIW is processing the expression ?
I stumbled onto my simple example - copied below - when a simple GPIW seemed to have a noticeable lag and lucked into the solution. The problem obviously escalates with more complex GPIW expressions, as per @palad0n’s example.
I cannot accept a 1800% degradation in performance. Who does?
As an engineer I would never do that.
Notwithstanding this, is there something within the beanshell , I call it, thingy, that can be 'fixed"?
This affects any Vassal feature that uses a conditional statement. Sorry I cannot think of any other particular instances ATM. Later today I will be going through my modules to ascertain which aspects can be speeded up by 1800%.
So, beanshell is a system of more levels of interpretation than the hand coded system. Thus, 1800% really means 18 levels of interpretation. Perhaps 9 levels one way and another 9 level returning.
Do not get me wrong, I really like beanshell (plus the other not quite beanshell java math stuff one can do). I just cannot comprehend how these conditional criteria can be so totally corrupt.
I believe that module developers should be given the wherewithal to use non bean shell expressions for those instances where beanshell is obviously deficient.
As to which instances where this applies, I will get back to this forum.
Unless someone beats me to it :-).
I also hope that my previous post will guide other module developers as to the way to go, for now at the least.
On another note. Have you noticed that I have used ‘Moved=true’?
In a conditional statement looking for true or false then simply stating Moved should be adequate. Conversely, !Moved should be the opposite.
But when I tried using just Moved it was ignored.
Would not these conditional statements be somewhat simpler if parts of it were just the property itself, not whether it was equal to true or false?
So instead of ‘yes’ or ‘no’, we can use ‘true’ or ‘false’, and where we require the inverse ‘!property’.
Possibly, I have not looked at the code. There may well be a bug there. I would be interested to see the timing difference between using a simple Beanshell expression vs Legacy for a GKC hitting the same number of counters. It should be similar to the GPIW case. If not, it could be poiting to a bug in GPIW where the expression is being calculated too many times.
I have no idea what you are talking about. They can be used anywhere a property match expression is used.
As Mark suggested, it could be pointing to a bug in GPIW. I would like to see a comparison of usage in GKC’s.
As I said earlier, Legacy expressions are quirky and illogical. They are what they are and will not be changed or developed further.
Experience indicates that GKCs derive no or little benefit from using the legacy mode conditionals. GPIWs, however, benefit greatly.
Just thought I should mention this.