Task #27165

Task #27064: Collect performance data, to collect reproducable & comparable speed/memory data

Reduce number of Object Manager calls / object instanciations in Fluid

Added by Bastian Waidelich almost 3 years ago. Updated over 1 year ago.

Status:Closed Start date:2011-05-31
Priority:Should have Due date:
Assignee:Sebastian Kurfuerst % Done:


Category:Extbase: - Profiling -
Target version:-
Has patch:No Complexity:
Tags:ETM, ETM2
Votes: 0


Originally from ExtbaseTeamMeeting 2011-05-31:

  • Jochen experienced that Object Container::call_user_func is costly
  • ➜ Sebastian will look into it

Further investigation:

  • Object Container is called a lot of times (roughly 800 times for displaying a list with three blog posts in the blog example)
  • 628 times (of roughly 800) a new object has been created (so it was a prototype or the first creation of a singleton)
  • 71 of the 628 are in the Extbase namespace, 554 in Fluid, 3 in Blog Example
  • -> Fluid improvements will be most beneficial:
  • Investigation of the 554 calls in Fluid:
    • 304 are dealing with the creation of the Syntax Tree (O1)
    • 61 create Tx_Fluid_Core_ViewHelper_Arguments, which is a simple wrapper for a read-only array (O2)
    • the 189 left are the following:
      • 40 are the creation of the ParsingState (O3a)
      • 43 are the creation of TemplateVariableContainer (O3b)
      • 76 are instanciations of some ViewHelpers (O4)

Long-term solution

  • Compilation of the syntax tree

Short-term solution:

  • Solution for (O1): Disable Dependency Injection for the Syntax Tree, as it is not really needed -> Instanciate syntax tree objects in Template Parser directly with "new".
  • Solution for (O2): use plain array instead of Arguments object
    • !!! breaks API, because Arguments has method hasArgument
    • -> Introduce a new method hasArgument on the AbstractViewHelper
    • -> can only be implemented after compatibility flag available.
  • Solution for (O3a,b): Needs to be investigated what the problem is there. I guess for every argument of a ViewHelper a new parsingstate and a new TemplateVariableContainer is created; although this is not really needed.
  • Solution for (O4): Reuse ViewHelpers without persistent internal state (which need to be marked with a special interface then) -> like the EscapeViewHelper, the Format ViewHelpers etc.

Evaluation with xdebug / kcachegrind

  • The evaluation is based on single runs, not multiple runs, which makes the data a little fragile -> will work on this, and try out xhprof.
  • However, the values are as follows:
run total time spent in Extbase total object creations in object manager
Baseline (Fluid master) 1,85s 628
Arguments optimization (O2) 1,88s (most likely a measurement error) 567
(O2) + Syntax Tree Object Creation (O1) 1,52s 270
(O2) + (O1) + Partially reusing ViewHelpers - partly (O4) 1,45s 206
  • This shows that O2 clearly brings the most benefit, and is still backwards-compatible. The only drawback is that Syntax Tree nodes can not be overridden using Dependency Injection anymore (which is a very very rare use-case I think).
  • note: of course, still the same number of objects is created, just using new directly instead of the ObjectManager.


Updated by Bastian Waidelich almost 3 years ago

  • Tags set to ETM, ETM2

Updated by Bastian Waidelich almost 3 years ago

  • Category changed from Extbase to Extbase: - Profiling -

Updated by Sebastian Kurfuerst almost 3 years ago

  • Status changed from New to Accepted

Updated by Sebastian Kurfuerst almost 3 years ago

  • Subject changed from Profile usage and evaluate replacement of call_user_func to Reduce number of Object Manager calls in Fluid

Updated by Sebastian Kurfuerst almost 3 years ago

  • Subject changed from Reduce number of Object Manager calls in Fluid to Reduce number of Object Manager calls / object instanciations in Fluid

Updated by Schmidt Timo almost 3 years ago

I think a problem is also the that even for a cache hit in the ClassInfoCache there goes a query to the database.
Due to the fact, that the object manager is used everywhere this produces a large amount of queries or file operations in
the cache backend.


Maybe some optimistic caching strategy that loads more data into the cache object would be gould to reduce the amount of querys/io produced by has and get.

Updated by Oliver Klee almost 3 years ago

For the same type of object created lots of times, it might help to create an "example instance" and then clone it instead of creating "really new" objects. (This is just a shot in the dark; I haven't done any testing on this yet.)

Updated by Bastian Waidelich over 2 years ago

I guess this can be closed since we have compiled templates!?

Updated by Markus Günther over 1 year ago

  • Status changed from Accepted to Closed

Also available in: Atom PDF