Re: storage leak and performance bug in schedule merging

[Rob Kewley]

Roger M. Burkhart wrote:
 
> The fix is very simple (patch line below), but the effect is very
> unfortunate.  Functionally, swarms have been executing actions in the
> proper order, but if you were using one of their major functions, to merge
> subschedules, you were probably seeing the slow-down effect.  Unless you
> merge your own schedules inside your own swarm, you may not have seen this
> effect in your own model swarm, but I have confirmed that the effect does
> occur even in a display swarm merging display actions with model actions.
> In this case, it could result in the display speed getting slower as the
> model runs, in proportion to the display frequency.  The fact that the
> effect has not been more glaringly obvious up-to-now must indicate how
> little the display merging actually consumes relative to other model and
> display operations, even after many accumulated display cycles.
> 
> The fix is to insert the following source line after line 43 of the source
> file activity.m in the activity library (either Swarm 1.0.1 or Swarm 1.0.2):
> 
>   [_activity_swarmSyncType setAutoDrop: 1];
> 

This fix solved the slow down problem in my experimental template code
and in my
battle simulation model.  In the battle model, not only did it stop the
increasing 
execution speed, it also sped up the initial iteration by 25%.  Thanks
for the fix.

Rob Kewley

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================