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

[Marshall, James A R]

Hi,
  is randomisation also an issue for inserting single actions into a
schedule? I'm inserting actions singly into a schedule using the following
code:

mSchedule.at$createActionTo$message(day, SuperDelegate.getInstance(), new
Selector(SuperDelegate.getInstance().getClass(), "deliverShipmentToPort",
false), shipment);

The thing is as the model progresses the argument day becomes progressively
larger. I believe that this is the root of the problem as the model starts
off running quickly and rapidly grinds to a halt, although the processing
load in the model should be roughly constant over time. So it seemed to me
that at$createActionTo$message might have a linear time cost based on the
time in the schedule you insert at, rather than something like constant or
logarithmic time. I haven't looked at the Swarm activity code to see if this
makes sense yet, but this is my intuition, based on the fact that simply
removing occurences of the above line and replacing it with my own hack
results in these massive speed increases (around 60x)
        James

---
Dr James A R Marshall
Complex Systems Modelling Group (COSMIC)
Department of Earth Science and Engineering
Imperial College London
Tel: +44 (0)20 7594 7493
Fax: +44 (0)20 7594 7444
Container World Project - http://www.ese.ic.ac.uk/research/containerworld/



-----Original Message-----
From: Paul Johnson [mailto:address@hidden
Sent: 18 February 2003 00:35
To: address@hidden
Subject: Re: [Swarm-Support] Time efficiency of
at$createActionTo$message


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

_______________________________________________
Support mailing list
address@hidden
http://www.swarm.org/mailman/listinfo/support