Profiling for this module

Sure, here we go:

For the test, I created three differnt kinds of nodes:

• Simple Node: This node is a very simple node with three fields: title, image and body.
• Node Complex Fields: This node has a load of fields: Text, Images and Field Collections within Field Collections
• Node Complex Preprocess: This are acually two kinds of node-types. They deal with entity references. A Sub Node can refer the main Node or another Sub-Node. The hierachical data model is two layers deep. During the preprocess they are loaded vie entity field query and rendered into the parents template.

I created the benchmark for 'Node Complex Fields' and 'Node Complex Preprocess' to figure out what the pros and cons of field cache vs. full cache are.

Additionally I run a benchmark with Panels. This is because panels uses entity_view() and if this function is called the renderable array is cached also.

The results in miliseconds are:

                          Node Type | No Chache | Field Cache | Full Cache |
           
                        Simple Node |    103    |      89     |      86    |
            Simple Node with Panels |    131    |     128     |     122    |
                Complex Node Fields |    348    |     216     |     200    |
    Complex Node Fields With Panels |    459    |     282     |     232    |
            Complex Node Preprocess |    496    |     481     |     295    |
Complex Node Preprocess with Panels |    533    |     515     |     315    |

I attached an image with a graph for a better overview.

There were an issue with caching the renderable array #1997458: It doesn't work!!.

So I re-run th benchmarks with full cache and panels. The new results are:

                          Node Type | No Chache | Field Cache | Full Cache |
           
                        Simple Node |    103    |      89     |      86    |
            Simple Node with Panels |    131    |     128     |     122    | <- No new result
                Complex Node Fields |    348    |     216     |     200    |
    Complex Node Fields With Panels |    459    |     282     |     127    | <- Just awesome!
            Complex Node Preprocess |    496    |     481     |     295    |
Complex Node Preprocess with Panels |    533    |     515     |     276    | <- A little bit less

Results with entitycache enambled:

                          Node Type | No Chache | Field Cache | Full Cache |
           
                        Simple Node |     95    |      94     |      88    |
            Simple Node with Panels |    131    |     122     |     117    |
                Complex Node Fields |    344    |     208     |     201    |
    Complex Node Fields With Panels |    395    |     242     |     123    |
            Complex Node Preprocess |    280    |     280     |      94    |
Complex Node Preprocess with Panels |    320    |     314     |     119    |

@thedavidmeister, yeah, rendering is stupidly expensive.

@Caseledde. I did some comparisons of display_cache with a custom solution I have, and I found that caching the html directly is quite a bit faster than just allowing core to cache the render array. My solutions suffers from the asset management issue, since #attached won't work, but that is something that display_cache can definitely solve . I did not do as formal a test as yours, but I saw extra improvements of up to 30%. If you have some time to waste, maybe you can see if this can be corroborated in a more formal manner, and I do not believe that it would be hard to modify the code to allow for this form of caching, if the user wants it.

Nevermind. I modified display_cache to save the html instead of the renderable array, but there was no significant improvement. Then I tested display_cache against my more simplistic custom implementation, and my implementation performs about 60% better. Then I had to do some profiling to see what was going on. During my test I profiled a page that displays 50 entities with their displays cached. While checking the profiling info I noticed that both methods call cache_get 50 times (obviously), yet the inclusive wall time of display_cache was around 235000 microseconds, while the inclusive wall time of my implementation's cache_get was around 45000. I guess I will have to dig into cache_get to see what could be causing the big difference.

#7 - You're absolutely right. Caching of the renderable array is waste if the rendered and cached html output already is an renderable array. (uses just'#markup' instad of all etc.) So display_cache_view_entity will return the cache entry from the rendered output now.

Just commited these changes.

@thedavidmeister I apologize for the stab in the dark, I just wanted to try to prove what I had claimed in #6, but ultimately it just brought new questions. I will continue to dig in, but I might not have any time until Friday. I will check the error logs to see if I find anything that seems related.

Am I reading #4 right? Does having Entity Cache installed along with Display Cache cause simple nodes to load slower? I don't understand why that would be the case.

Just a question: how should I include my display-cached node in Panels (with the provided Node template) to have the best performance?

1. Entity,
2. Node,
3. or Existing node?

The panes you get are called:

1. Rendered Node using view mode "Full content",
2. "Node being viewed" content,
3. Node loaded from @0

which of course render the same content, but code/performance may differ?

Do we want to continue this ticket? Or is it done? Updating isn't out of the question. And wouldn't the result charts benefit the project detail page for others to see there is clear performance net gains for some sites using this module.