Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have come up with a way to reduce render time considerably on larger matrices (as they often are, in my experience). I profiled a bit and found that a large part of the page load is taken up just by theme('views_view_field') calls – which makes sense, of course. You have (normally) at least 3 fields active, and for 2000 results (e.g., a 200x10 table) that will amount to 6000 field renders.
However, actually only 2000 + 200 + 10 = 2210 rendered fields are displayed – the column and row header fields are rendered for each result, but only used once per column/row.
Building on this, it was almost trivial to change the display plugin to avoid all those unnecessary render operations. Patch attached – and it really does wonders for large matrix views.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2389993-4--performance_improvement.patch | 2.97 KB | drunken monkey |
Comments
Comment #1
mradcliffeThat makes sense. As much code that can be put into the style plugin the better.
I really need to set aside one of my Saturdays just to views matrix. Core has been a big distraction lately and I apologize for not reviewing lots of patches.
Comment #2
herd45 CreditAttribution: herd45 commentedI've tested this on three different Views and it consistently reduced page load time by around 1 second. All three of the views were around the same size that drunken monkey mentioned in his example. The most basic of these views has gone from 3.5 seconds to 2.5 seconds.
Comment #3
mradcliffeI was able to go through and test the patch, and I found some issues when adding field api fields.
Here's another patch. I'm sorry for not paying attention as Drupal core development has a lot of my attention that I can devote recently.
I ran through a test of fields with multiple values, empty text, term reference fields and those checked out.
Comment #4
drunken monkeyThanks for taking a look at it, and sorry this again took me so long to get back to.
I didn't test it with Field API fields, so thanks for correcting that. However, with your change, it seems this doesn't use the performance improvement after all for Field API fields. I think just serializing the array to arrive at a string to use as the key should also work, but keep the performance improvement. (
$valueis only used as a key for the array of cached render values, so it doesn't matter if its value doesn't make sense, it should just be different for different field values.)However, I also noticed another thing: in my code, for each result I first render the column and row header fields, and only then all the others. While this sometimes works fine, it will break if any row tokens are used in one of the header fields. For tokens to work correctly, the fields have to be rendered in the exact order they appear in
$view-field. Luckily, that's pretty easy to change. Please see the attached patch, which now seems to work completely fine!Comment #6
drunken monkeyCommitted.
Thanks again for your feedback!