Marker Trait - Single value or multiple name/pair

Module Design
1

Just wondering. Is it better, in terms of efficiency, to use a bunch of single marker traits or one marker trait with multiple name/pair? The thought arose from a consideration of how Vassal parses through the traits when doing ‘stuff’. Thus, I tend to believe that one marker trait with multiple name/pair would be far more efficient.

2

The answer to that question, I should think, very much depends on how the values are used.

Suppose you have 5 properties P1,…,P5, with values V1,...,V5.

  • If these properties are always present (i.e., all relevant pieces has all properties),
  • the properties are always used together (e.g., you always add them up, or some other operations), and
  • you have a reliable way to extract the values so that you can operate on them

then, maybe, there could be a point in storing them together as a single “master” property - say PX. You could store the values as a text string like

V1|V2|V3|V4|V5

(note you are not completely free to choose the separator due to VASSAL’s rather fragile way of parsing trait values - , and \ are for example bad choices). Now you can extract the individual values by parsing out with BeanShell parsing a la

PX.split("|"][0]+PX.split("|")[1]+PX.split("|")[2]+PX.split("|")[3]+PX.split("|")[4]

which is not very effective since we’re doing the same .split("|") five times. You could of course have five CalculatedPropertyTrait traits, but then the idea is kind of out the door. Of course, if you do no (or very minor) operations on the values, then the overhead is probably not that big - but there’s still an overhead.

For these reasons, I think it’s unlikely that there’s a performance benefit.

When VASSAL is looking for a property in a piece,

  1. it starts from the outer most Decorator (Trait) and queries for that property.
    1. If that decorator has that property, then that properties value is returned.
    2. If the decorator does not have that property, then the decorator forwards the request to the next decorator down the stack - i.e., goes back to “1”
  2. If no decorator had the property, then the request may be forwarded to the containing Zone, Board, Map, and eventually Module.

But all this happens in (byte-)compiled Java code - not interpreted BeanShell code.

So, in fact, looking up a property of a piece isn’t all that slow even though it can generate a rather deep stack (or maybe not if the loop is unrolled).

Various optimisations could be done - like caching property names and links to them in an associative array, bulk queries for all needed properties in a BeanShell expression, and the like. However, there’s a relatively good chance that those optimisations won’t really mean a whole lot for the performance due to other overheads. Again, it depends a lot on how many and how often look-ups are being done.

As I said above, I highly doubt that. But there’s no way to know for sure without conducting the experiment - ideally with a profiler.

Yours,
Christian

3

Thanks for your response Christian.
I already use some multiple name/pair traits and I have not found a need to parse them to get the values. I just use the trait name to get the value. Vassal does not seem to have an issue with using ‘,’ as the delimiter between names and their values.
That said, you are probably right in that it makes little difference in ‘computing’ time to get a marker trait name’s value, whether that is via multiple marker traits or via a multiple name/value pair marker trait. Single marker traits are probably easier to use as a multiple marker trait can be somewhat difficult get the right spot for a value when entering values.
Again thank you.