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'm wondering whether the views plugin data should be cached as they might produce quite some calls to t()
Comment | File | Size | Author |
---|---|---|---|
#4 | cache_views_plugin_data-1376400-4.patch | 1.78 KB | fietserwin |
#2 | 1376400-2.patch | 1.16 KB | fietserwin |
Comments
Comment #1
fietserwinI was playing a bit with the new Zend Server Z-Ray tool and found indeed that getting this info consistently takes over 10 ms on my local machine (all included data and programs on sdd, internal memory by far not exhausted). So a big yes to this feature.
To give it a kick, a first try.
Comment #2
fietserwinOK, if I post a patch, I can as well post a working patch, not just "a hint of how it could be done" :)
2nd try:
- working code.
- cached per language as the data contains translated strings (that's why we want to cache it...).
- execution time of _views_fetch_plugin_data() reduced to around 3-4 ms.
Comment #3
das-peter CreditAttribution: das-peter commented+1 to for caching.
Visual review looks good, only thing I found is this:
Throughout core following pattern is more common:
if ($cache = cache_get($cache_key)) {
Comment #4
fietserwinThanks for reviewing. New patch attached. I found a bogus invocation that might defer any gains (though it did not in my local test). Feel free to not include that part, or open a separate issue for that, if there's something really wrong at that point.
Comment #5
Kars-T CreditAttribution: Kars-T commentedI ran the patch from #4 against my project and it doesn't seem like it broke anything but speed things up. The caching by language seems very reasonable. And the removing of the array from pager_plugin is wise as well or it will never cache.
From the code the patch seems clean. I think it is RTBC.
Comment #7
dawehner10ms is not that bad, honestly.
Committed to 7.x-3.x and pushed