Re: [Swarm-Support] Time efficiency of at$createActionTo$message

[Paul Johnson]

I know about this problem with createActionForEach, when randomization 
of actions is turned on. I guess if you have randomization turned on 
anwhere and you keep adding actions to the schedule at the same time, 
then you will see that huge slowdown.

The randomization causes a slowdown because, each time "next" is called 
in the current schedule, it stops to shuffle all of the actions again. 
Then "next", then shuffle again. This is necessary because it is 
conceptually possible for people to insert actions into running schedules.

The activity library is very complicated and I've often thought this 
should be dealt with, but it is not attracting much interest.

Can you tell me the exact syntax you are using? I'll compare against the 
Objective-C and see if I get exactly the same result you do.

I posted about it a while ago about the 
createActionForEach/randomization problem and learned that it is a fact 
of life.  If you schedule one action and then have that call a method 
that iterates over a list, you do get the massive speedup you describe. 
 It has led me to pretty much drop the use of createActionForEach in 
any big model.  Or randomization.

Marshall, James A R wrote:
> > Hello,
> >  today I've had a rather nasty surprise to do with
> > at$createActionTo$message... our model wasn't scaling well and after 4
> > days of checking out my own model code I found the apparent culprit...
> > at$createActionTo$message. The larger our simulation (i.e. the more
> > events) the worse the behaviour of at$createActionTo$message...
> > particularly I think that at$createActionTo$message does not work in
> > constant time according to the position in the schedule that you wish to
> > insert. When removing the calls to at$createActionTo$message and replacing
> > them with my own mechanism I managed to get a 60x and upwards increase in
> > execution performance (obviously the more events you schedule in the
> > future, the better the improvement). This is staggering. I've looked at
> > the FAQ and not turned anything up, so the purpose of this message is to
> > see if anyone else has any similar experience or expects this kind of
> > behaviour. The documentation also doesn't mention anything about the time
> > complexity of using this method     When I find time I'll delve deeper,
> > look at ways to improve this behaviour, etc. but in the meantime it seems
> > that a health-warning should be put on this method and presumably similar
> > ones. I'm using Swarm 2.2 pre-test 6 with Java 1.4.1 on Windows 2000 by
> > the way...
> >         James
> >
> > ---
> > Dr James A R Marshall
> > Complex Systems Modelling Group (COSMIC)
> > Department of Earth Science and Engineering


--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700