When a (key) command hits a piece, I believe all traits are queried to see if they will handle the command. Also, command execution does not stop on the first match, but continues until the traits are exhausted. Also note that the traits are search twice - see Trait Ordering and YOU, possibly with some caching.
In short, the execution time of any command hitting a piece should be order N where N is the number of traits - i.e., take proportionally longer the more traits your piece has.
This could be optimised in the Vassal code by caching acceptable commands of a piece - preferably in a hashed associative container for quick look-ups.
Looking up a trait to see if it will handle a command involves string comparison. String comparison is best-case complexity O(1) (different size strings) and worst case O(n). Or, the time to execute a comparison between two string is constant and independent of the string size n if the two strings compared are of different length. If the strings are of equal length, then n characters need to be compared:
FUNCTION string_compare TAKE S1 A string AND S2 A string DO
IF length of S1 NOT EQUAL TO length of S2 THEN
RETURN false
END IF
FOR index FROM 0 TO length of S1 - 1 DO
IF character at index of S1 NOT EQUAL TO character at index of S2:
RETURN false
END IF
DONE
RETURN true
END FUNCTION
That is, comparing long strings to other long strings does take longer, especially if the strings are more or less of equal length.
That said, the string comparisons at play probably take far less time than the iteration over the traits container, so there’s probably very little to be gained by shortening the strings.
But, if you make all command the same length, then all string comparisons will be O(n), while if they have variable length you will often hit the O(1) - simply because the strings are of different length.
Sure, string comparisons can be optimised under certain assumptions. One can use use hashes of the strings if one is sure there’s no collisions, which may be at the cost of increased time in calculating the hash-values. One can cache these hash-values - for example in a associative container where the keys are the hash-values.
One also has to weigh up the benefit - for maintenance etc. - of more descriptive strings versus the time spend and the possible gain.
The real killer - in terms of time - is typically BeanShell expression. Evaluating a BeanShell expression involves setting up and tearing down the interpreter environment, which takes non-trivial amount of time. Check that you are not evaluating a lot of BeanShell expression - for example in Calculated Property traits.
Yours,
Christian