I’ve come across a rapid fall off in performance when I add an existing prototype to a second piece. Granted the second piece is a bit more complex, but the fall off in performance is from near instantaneous to a 4-5 second lag in the second piece, and a 2 second lag in the original piece. I can make the module available if someone is willing to take a look.
Further, are there any guidelines to follow to prevent this from happening? Are prototypes intrinsically slower than having the properties within the piece?
Oddly enough, when I remove the prototype from the large (many property) piece, the fewer property piece “speeds” back up.
Exactly what is in the ‘existing prototype’. How many traits do you estimate it contains? Homw many traita do you estimate a complete counter contains. From your previous email, I am thinking hundreds?
There is a cost involved in each additional trait added to a counter, it slows down access to any properties declared ‘inside’ that trait, including all Vassal defined properties. Access time to any property is proportional to the number of traits defined ‘above’ it. All Vassal defined properties (e.g. selected, PieceName, LocationName etc.) are defined at the bottom of the pile and so are maximally effected by additional traits piled on top. Additionally, there are properties that you don’t see that are being accessed by Vassal on your behalf.
We are aware of the problem and have plans to ‘do something’ about it. It is not a trivial thing to fix since the multi-level access to properties is important for some properties, as the value returned by some properties is modified or blocked by the traits above it. However, some properties (LocationName is a good example) are never affected by traits above it and should be returned from the ‘top’ level without having to recurse down through the trait stack.
Yes, I would be interested in having a look, but I can’t guarantee there is anything that can be done.
Define your pieces with fewer traits.
Define traits that return properties (e.g. Markers, Dynamic Properties, Property Sheets) as ‘high’ in the stack as possible (i.e, further down the list in the piece definer, and in a prototype further down the list).
No. Prototypes are completely expanded and the resulting piece is indistinguishable from one created without prototypes. However, with regard to the previous answer, if all your properties are defined in one prototype, then the position you place that prototype in the piece definer will be significant.
I suspect the ‘complex’ piece is chewing up all available CPU power to process the property value requests, thus slowing down all other activity.
Thanks for willing to look at this Brent. I place the module in Chivalry & Sorcery with the name forBrent. The offending piece is “New Character Sheet”, and the offending prototype is actionCard (not Action Buttons).
To reproduce: Start the game as GM and with the smaller map 4800x???.
Use the piece palette to drag/create a “New Character Sheet” piece. The trigger (CTL T) will demostrate the problem (which can also be performed by pressing the Great Blow (row 1 column 7) button under Right Arm Actions.
Pressing any of the other buttons will change the buttons listed (via a layer) This function is relatively fast. I’ve place the prototype actionCard at both the top and the bottom of the “New Character Sheet” properties list.
The piece action card works in similar manner. I was originally going to generate action cards that would then generate event cards, but due to the need to update information on the character sheet resulting in the need to generate a new set of action cards, I thought it was be better for play to combine the action card and the character sheet into one piece. You can delete the prototype from “New Character Sheet” properties and watch the action card “speed up.”
I don’t have great news for you. It looks pretty much as I expected, the ‘New Character Sheet’ piece is just way too complicated and contains too many traits. Adding the ActionCard prototype just puts it over the edge.
I didn’t really follow your explanation, because the Trigger action seems to be in the ActionCard trait, triggering off 6 other keys. There is no way I have the time to track down exactly what is going on, but there are obviously hundreds of traits in the piece.
Well thanks for at least looking at it. I’m going to try a couple of things. The first is to eliminate the action cards. As they are combined into the character sheet, they were on the hit list anyway. The reason to attempt this is that eliminating them is that eliminating it from the character sheet greatly increased the speed at which the action cards worked. I hope the converse will hold.
As for the complicated nature of this piece, well it really isn’t yet. All it is are action buttons and text labels. I can give you a blow by blow description of what this piece does with the trigger action, it is only about 18 steps. It fans wide at the start, but is very shallow.
The next thing I will do is start playing with the prototypes. Either eliminating them or insuring that they do not contain too many properties. I think there is something going on there (perhaps some type of nested recursion - it is java afterall.) When I originally described the problem in the module design section I mentioned that having over 15 text labels in a protoype ground the piece builder software to a halt. Reducing that to only 10 speed it back up. This was BEFORE I added the trigger action, so that wasn’t even a factor.
I actually tried a few of these, by the time I write this section. Keeping the same number of total actions(properties), but dividing the number of properties in the Action Buttons prototype helped quite a bit. Just FYI.
A word of caution: Since we have a general solution in the works for the
performance problem you’re seeing, you should consider whether it’s worth
it to sink a lot of time into optimizing what you have now. This won’t be
in 3.2, but should be in 3.3. If you’re not planning to finish the module
for 6-8 months, then it might make sense to save yourself some time and
wait for us to fix the underlying problem.
Waiting is not a problem, being told that it isn’t an issue would be. I’ve been waiting for 3.2 for 6 months now, and other than an every 3 month jingle to ask how it is going, I think I’ve been and plan to be supportive. Especially since I’m just sitting back making modules and not helping with the development.
So I’ve thought about it today, (and wasn’t able to increase the speed much more), I can work around it by adding back in the action cards. Even from the playing the game stand point, it almost makes sense. Action cards for a given character only change if certain big changes occur. These changes should be rare, other than having a weapon knocked out of one’s hand. In fact, I can use the replace with trait to convert the cards as these changes occur.
In addition, I was already starting to get confused what did what without the prototypes. So other than a little global variable bookkeeping, having the character sheet generate action cards with action buttons, and then having the actions card generate the events, should work well and will even help me document the module as I build it.
Obviously you can see that with this many triggers in the module and the wish to use math in triggers, I can hardly wait to see 3.2.
This fix won’t be in 3.2. It will be in 3.3. The only projects I’m working
on which will be in 3.2 are Properties, Preferences, NIO2 File Systems, and
Tile Cache. (See vassalengine.org/forums/viewtopic.php?t=2577.)
The project corresponding to the fix for your problem is “Conversion of
Buildables to Use Properties”. This problem is important to me—the whole
purpose of the Properties project is to pave the way for this one.
Thanks. I realized that this fix would not be in 3.2. I’ll be happy with named triggers and math in 3.2. Here’s to 3.3 - whenever. (And the reason I’m planning to break the piece down.)