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

[Paul Johnson]

Dear Marcus

Thanks very much again for this assistance.  I'm still stuck on the 
randomization slowdown and the more I stare at the activity library,
the more confused I get.

So I have a novice activity library question.

As it is currently done with randomized concurrent groups, for each 
"next action" processed at a given time (terminology: in the concurrent 
activity set?) the whole list of actions is shuffled and then the first 
one is taken with a next. Right?

Would it not be faster to use NSelect to randomly select one?

I think I would run into the problem that it is slow to remove that one 
from the concurrent set after it is processed. But that would not be so 
slow as reshuffling a whole collection, would it?

I expect you are tempted to say "implement it and see for yourself". But 
I'd rather have some speculations from you first to consider whether 
this is likely to be of any use before I get all confused in the 
activity library.... :)

Marcus G. Daniels wrote:
> Marshall, James A R wrote:
>
> 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.




--
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