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.
Problem/Motivation
I've been profiling a site for performance recently. And wysiwyg_filter_parse_valid_elements() keeps coming up as a badly offending function. In the case of this site, there are multiple textfields on my content type that all use the same WYSIWYG filter. The list of $valid_elements never changes. Rather than calling this fairly expensive function for each of them, utilize the drupal_static pattern.
Proposed resolution
Utilize the drupal_static pattern.
Remaining tasks
User interface changes
n/a
API changes
n/a
Comments
Comment #1
heddnThe performance difference on a node that has 6 text fields.
Without patch: Times called: 6 | Total Self Cost: 3.39 | Total Inclusive Cost: 4.08
With patch: Times called: 6 | Total Self Cost: 0.63 | Total Inclusive Cost: 0.76
This means that each call to wysiwyg_filter_parse_valid_elements() takes approximately 0.60ms. If you have a lot of text fields or are loading a lot of data with node_load_multiple() or are using Views on a large number of nodes, this will take 0.60ms for each of those fields.
A further example:
10 nodes in a view with 5 fields each = 30ms
vs.
approximately 1ms with the patch.
Comment #2
joelpittetThis is great! I had one view that was reporting 1.3secons and this patch brought that down to 2ms!
Thanks @heddn
Here's a git diff -w . view of that patch because it looks bigger than it is.
@heddn it may be worth writing that with a an early return to make the diff smaller and less indenting?
aka:
Let you or the maintainer decided which is preferred
Comment #3
brockfanning CreditAttribution: brockfanning commentedI lean towards smaller patches myself, so just putting up joelpittet's suggestion in case the maintainer feels the same. But credit for this issue should go to heddn and joelpittet for seeing/fixing/testing the problem. Thanks guys!
Comment #6
geek-merlin