swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marshall, James A R
Subject: RE: [Swarm-Support] Time efficiency of at$createActionTo$message
Date: Wed, 5 Mar 2003 15:16:06 -0000

OK, that's great, I managed to get a good improvement in one of my models by
doing what you suggested.
  Now for my next question:
once you create an FCallImpl object, is it possible to change the target
and/or argument for subsequent re-use?
  In my very large model which was running into the serious execution time
problems I described, I'm continually scheduling the same message to the
same target, but with a different argument each time. Similarly I would like
to use probes in one of my utility classes, in which I call the same method
repeatedly on many different objects (I think this is related). Can I do
this or will I have to come up with my own method of doing it?
  Thanks,
        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: Marcus G. Daniels [mailto:address@hidden
Sent: 19 February 2003 14:41
To: address@hidden
Subject: Re: [Swarm-Support] Time efficiency of
at$createActionTo$message


Marshall, James A R wrote:

>You really need to drop Selectors? The Swarm Javadocs show Selector
>inheriting directly from java.lang.Object and not implementing drop itself.
>
It's not an issue of failing to drop them.  The thing to keep in mind is 
that as Java objects are exposed to Swarm, an association between that 
Java object and the Swarm native object must be maintained.  For 
Selectors there is an explicit yellow pages (in earlier versions of 
Swarm there was a yellow pages for objects too -- now those objects are 
available as slots in the objects themselves and there is not the lookup 
penalty).  In the case of making lots of new Selectors, you are creating 
a many to one relationship in this yellow pages, e.g. a bunch of 
different names for the same phone number.  As more and more objects get 
added to the yellow pages, things will get slower and slower because the 
directory takes longer to search.

The solution I would suggest is not to allocate more than one Java-side 
selector.  One good way to do this is to use the FAction idiom as in the 
example I posted, but cache the result of `createCall' in an ivar.   
Then you'll have a speedy call and you can focus on understanding the 
remaining performance problems, if any.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]