commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R.C. Hoekstra" <>
Subject [scxml] profiling scxml commons
Date Wed, 18 Jun 2014 07:42:08 GMT
Hi all @ scxml commons. 

We had some profiling done on our scxml multi agent simulation project. Our issue is that
scxml is too slow. We need about 100,000 instances of scxml engines for a multi agent simulation,
and tests show that the approach with scxml is over 10 times slower than an alternative but
less flexible approach. Still, the flexibility of the scxml commons project serves us very
well, so we need to look for ways to improve the performance. 

For our project setup see my mailing to this list on Fri, 30 May, 20:45.

We have the following tips and improvements: 

1) Now, there's a logger applied for each instance, which is inefficient. 

Make default Log in SimpleContext static. In SCXMLExecutionContext/SCXMLExecutor, it can be
static final even.
public class SimpleContext implements Context, Serializable {
   /** Implementation independent log category. */
   private static final Log DEFAULT_LOG = LogFactory.getLog(Context.class);
   private  Log log = DEFAULT_LOG;

2)  SimpleContext containsKey() + get() to get()

you can rewrite SimpleContext to:
   public Object get(final String name) {
    Object localValue = getVars().get(name);
       if (localValue!=null) {
return localValue;
       } else if (parent != null) {
           return parent.get(name);
       } else {
           return null;

We think item 1) & 2) will lead to a 30-50% improvement in our scenario, and they are
very simple to apply. 

3) Other issues we are not sure about: 

- Status.getAllStates can probably be cached: Difficult to determine if this can be done since
the states member is writable from outside and not sure when this getAllStates() cache should
be invalidated. But it takes up quite some time.

- SCXMLSemanticsImpl.isLegalConfig is probably a paranoia check, can we disable it?

4) Some questions about further speed improvements: 

4a) scripting:

In the configuration as given, about 10% is spend in JEXL scripting. Depending on how much
we want to do with that, we could switch to another scripting implementation (would require
some benchmarking) or maybe move some of the scripts into the Java domain.

Do you guys have any clues about which of the provided scripting implementations is expected
to be the fastest? Are there other possibilities to improve the scripting performance?

4b) initializing / common stuff:

What happens now is that each StateMachine engine (SCXMLExecutor) is instantiated a thousand
times, once for each agent. Maybe it's possible to move some of the stuff to some common initialization
where it is now done for each agent. Do you see any opportunities here?

kind regards, 

Rinke Hoekstra.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message