commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] Memory leak, performance problem
Date Sat, 05 Aug 2006 00:21:44 GMT
On 8/4/06, Heiko.Eichberger@rsbick.rohde-schwarz.com
<Heiko.Eichberger@rsbick.rohde-schwarz.com> wrote:
>
> Hi,
>
> we are working with SCXML extensively for quite a while. Its a great tool,
> its saves a lot of development time and makes things easier. But there are
> some impacts we discovered:
>
> - After a period of time triggering a lof of events, that contain
> assignments, variable creations and notifications of the EventDispatcher,
> SCXML seems to loose memory.
>
<snip/>

Requiring more memory when more variables and notifications are
created is expected (and depending on what objects the variables are
actually referencing this might be non-trivial), but a leak would
actually constitute holding on to these references for too long (or
eternity, even). Any particular bits where you think we should be
letting go sooner?


> - SCXML uses a lot of processor time, when large amounts of events with
> conditions are compared. A way to improve performance could be to compile
> JEXL expressions in TransitionTarget at load-time of the SCXML file.
>
<snap/>

Fair enough, the real issue here is that while a particular expression
language might afford us these conveniences, others may not and it
does get slightly tricky when you abstract out to a EL-agnostic API
(as Commons SCXML does) to do this at document load-time (where you
don't care about the EL yet).

However, there should probably be some caching strategy within the
particular Evaluator implementation (in this case, JEXLEvaluator)
where possible (so atleast when the same expression is evaluated
repeatedly, it isn't reparsed). Another place where a performance
penalty is incurred is to find the effective JEXL context since there
are no "chained" contexts out of the box provided by JEXL. I keep
meaning to add such an impl to JEXL, hopefully I'll get to it soon.


> - For each TransitionTarget, a JexlContext is created. For us, it is very
> important to have one context with all variables that is valid for all
> TransitionTargets. Is there a simple way to achieve this?
>
<snip/>

The SCXML Working Draft requires us to have separate contexts, so we
can differentiate between the two "foo" variables here:

<scxml ...>
 <state id="state1">
  <onentry>
   <var name="foo" .../>
  </onentry>
 </state>
 <state id="state2">
  <onentry>
   <var name="foo" .../>
  </onentry>
 </state>
</scxml>

I'm personally fine with providing a switch on the executor that
allows turning this behavior off and creates a single / flat context
for the entire document as long as that is conscious developer choice.
If you want, you can open an enhancement request in JIRA [1] for this
"non-standard" requirement.

Finally, thanks for your feedback. Its critical to the component's
continual improvement.

-Rahul

[1] http://issues.apache.org/jira/browse/SCXML


> Regards,
>
> Heiko
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message