commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Woonsan Ko <>
Subject Re: our project setup: any tips specifically on performance/speed?
Date Fri, 16 May 2014 17:17:32 GMT
Hi Rinke,

I think you can measure a rough range of how many times to invoke SCXMLExecutor (#go(), #triggerEvent()
for instance) in simulation on N instances. Then you'll probably able to get an estimate of
the total execution time somehow.
If the estimate of the pure SCXML executions can possibly meet your requirements, then I think
the next thing to consider might be how to reduce IOs if you have to (de)serialize those instances.
In one of our projects, we initialize a root context and an executor every time before triggering
events. So, the SCXML definition is responsible for initializing itself (to move the right
current state) from the given root context (in script blocks). I think this pattern could
help reduce the amount of (de)serialized data, and so reduce IO.



On Monday, May 12, 2014 12:58 AM, R.C. Hoekstra <> wrote:

>Hi list, 
>As written before, We're a university team of scientists working on multi agent simulations
of tropical diseases for a world health organization project. A disease can be considered
as a state machine, with the patient going through various states and transitions, each triggering
new events.
>We've managed to make a working example of a xml file where a patient is going through
various stages of the disease, including treatments with medicine. Our most important concern
at the moment is: how efficient is it? Our aim is a multi agent simulation with possibly a
few 100,000 of instances of a State Machine engine (SCXMLExecutor). I'd like to share the
code setup with you guys, and maybe you can give some clues on how efficient it will be in
terms of performance/speed, and maybe some hints if an alternative approach would be better?
>general setup
>we have a Population object (a wrapped list) containing all agent objects. Each agent
is assigned an SCXMLExecutor as the engine, so there are many instances of SCXMLExecutor.
We use the default JexlEvaluator, and each SCXMLExecutor gets the agent it belongs to assigned
to the rootContext, so the agent's properties can be accessed from the scxml file. 
>Our transitions are usually of a special type: a patient usually stays x days in a certain
state, after which the transition takes place. The x days is determined on basis of drawing
a random number from a statistical distribution. There is usually more than one possible transition;
each with different probabilities. 
>So the scxml file must contain the following information: 
>* distribution name and parameters to determine the time until next transition.
>* A number coupled to each possible transition indicating the likelyhood that it happens.

>We solved this in the following way:
>* distribution name, mean and variance parameters, and chances are defined in the datamodel
as single variables: <data id=”distr”>
>in each state's onentry we set these variables with the values specific for that state,
via the assign tag. The chances variable is defined as an array: 
><assign name="chances" expr="[0.05d, 0.10d, 0.20d]" />
>* The state's onentry also contains a send tag. Send passes the agent's id, the forementioned
variables and the event concerned. 
>The send message is captured by our own implementation of EventDispatcher. This does two
>** It draws the random time based on the passed distribution parameters. It schedules
this in our own discreet event manager. When the desired time has passed, the discreet event
manager passes the correct event back to the correct SCXMLExecutor instance. 
>** It determines which transition will be chosen by drawing a random number on basis of
the chances array. This results in an index number of the transition to be chosen. This index
number is passed as payload to the event. The scxml file checks this index number in the cond
attribute of the transitions.
>Agent properties:
>Each disease state also has its effect on the agent's properties, for example the infectivity
of the agent, or its fitness. The agent was passed to the rootContext, so the onentry of each
state contains code to set the agent's properties specific to that state: 
>                <script>
>                    agent.infectivity = 1
>                </script>
>This is our overall approach. I'd be happy to receive any comments; specifically tips
regarding the expected speed/performance. 
>best regards,
>To unsubscribe, e-mail:
>For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message