[
https://jira.jboss.org/jira/browse/BPEL-311?page=com.atlassian.jira.plugi...
]
Aleksander Adamowski updated BPEL-311:
--------------------------------------
Attachment:
org.jbpm.bpel.graph.def.CompositeActivity.findVariable.Call_graph.single_operation-expanded.png
Here's a simple call graph from JProfiler, illustrating who calls who.
Notice how the calls to findVariable are recursive, and how their invocations are passed
through Hibernate's JavassistLazyInitializer, putting great stress on Hibernate as a
side effect.
Performance improvement: Find a way to reduce number of
org.jbpm.bpel.graph.def.CompositeActivity.findVariable() calls
----------------------------------------------------------------------------------------------------------------------
Key: BPEL-311
URL:
https://jira.jboss.org/jira/browse/BPEL-311
Project: jBPM BPEL
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Engine
Affects Versions: jBPM BPEL 1.1.1
Reporter: Aleksander Adamowski
Assignee: Alejandro Guizar
Attachments:
org.jbpm.bpel.graph.def.CompositeActivity.findVariable.Call_graph.single_operation-expanded.png
According to our profiling data, during a single invocation of a relatively simple
business process (cannot post it here for confidentiality reasons), jBPM-BPEL performs an
unreasonable number of findVariable() calls.
Using JProfiler, we've recorded almost 150000 findVariable() calls for a single
process execution (the process definition contains only 31 bpws:variable elements
collectively).
I suspect that there's some algorithm which runs in exponential time with respect to
the number of variables or activities. Maybe adding some form of variable caching could
enable dramatic performance improvements?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira