Uploaded image for project: 'camunda BPM'
  1. camunda BPM
  2. CAM-2725

Unexpected performance hotspot in ExpressionFactory.newInstance



    • Bug Report
    • Resolution: Fixed
    • L3 - Default
    • 7.2.0, 7.2.0-alpha6
    • 7.1.0
    • engine
    • None


      When profiling a process we found a performance problem inside `ExpressionFactory.newInstance`. This method uses some complex logic of looking into `META-INF/services`, the home directory or a system property to decide which implementation to instantiate using reflections.

      Normally this should not be a problem since the factory could be reused. There is however one constellation where this method gets invoked repeatedly: When an EL expressions uses method calls an ExpressionFactory is created to coerce argument types. This instance is then cached on the `BeanELResolver`, but this cache is not reused across subprocesses.

      A testcase that can be run in a profiler is available at <https://github.com/jhorstmann/camunda-engine-unittest/tree/expression-factory-performance>. A screenshot of a profiling run is attached. The effect could be more pronounced in a bigger application with larger classpath or when running in a container with several class loaders.

      There are several possible improvements:

      • Argument type coercion would not be needed for methods without arguments
      • The BeanELResolver could be reused across ELContexts (ELContext itself is not threadsafe, but the resolvers should be. This might give more performance benefits since BeanELResolver contains a cache of bean properties.
      • The lookup inside ExpressionFactory.newInstance could be simplified if it not actually supported to replace the expression language used inside the engine. This is the approach I'm currently trying.


        This is the controller panel for Smart Panels app


          1. profiler-screenshot.png
            75 kB
            Jörn Horstmann
          2. profiler-screenshot-with-fix.png
            47 kB
            Jörn Horstmann



              thorben.lindhauer Thorben Lindhauer
              jhorstmann Jörn Horstmann
              0 Vote for this issue
              4 Start watching this issue