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.
The render_time metric is set after all Views hooks have been executed for a single View. Is there anyway to access this timing using a standard API function?
Comment | File | Size | Author |
---|---|---|---|
#6 | views-render_time_metric-1809510-6.patch | 663 bytes | erikwebb |
Comments
Comment #1
dawehnerYou can look it up on the view object: $view->render_time.
Comment #2
erikwebb CreditAttribution: erikwebb commentedThe problem is that $view->render_time is not available during hook_views_post_(build|execute|render). I even looked for it in template_process_views_view(), but it still was not set there either. The only way I was able to retrieve this metric was by overriding the theme function, which doesn't seem like the right solution.
Comment #3
dawehnerMh good point.
I'm wondering whether hook_views_post_render should maybe fired after measuring the render_time, do you have an oppinion about that?
One thing you could do, but pssst you could alter the $view object and maybe replace it
with a decorator version/ a which which extends the normal view class.
If you do this you could fire some hook or something similar later.
Comment #4
erikwebb CreditAttribution: erikwebb commentedI guess it depends on if we consider "render time" to include only the time required for Views to render the output or if we want to include any work done by modules in hook_views_post_render() implementations. I'm comfortable with this switch, but I'm not sure if there are any implications that I may not be familiar with.
Comment #5
dawehnerAt least at the moment probably not may people are using the render time on actual live installations, but just in the admin interface
, so it seems to be safe for me to move this property up. With this hook_views_pre_view and hook_views_post_render you could
even build your own measurement, just throwing out some ideas.
We have considered to remove this property totally for live-views in d8, but that's not decided/done yet, but it's good
to know an actual usecase.
Regarding the decorator idea, here is a short codesnippet. I'm not sure about the performance implications, but they simply can't be positive :) Once you have this decorator in place, you can change the way for example the render method works.
Comment #6
erikwebb CreditAttribution: erikwebb commentedSearching drupalcontrib.org for implementations of hook_views_post_render(), I actually don't see any. I think we can go ahead and move where this value is set.
Comment #7
erikwebb CreditAttribution: erikwebb commentedLong-term I'd like to use this metric to analyze the performance of individual Views on a site. Currently it's difficult to do that using something like New Relic or XHProf, because the function calls are all mostly the same.
For the sake of completeness, here is an example as I see it being used -
Comment #8
dawehnerCommitted this patch to 7.x-3.x
In drupal8 we actually try to remove this completly because we nether thought that this will be used on the actual live site, see #1811982: Remove ui preview logic viewExecuteable::render() and move it to viewUI. Your oppinion. is greatly appreciated.
Comment #9
erikwebb CreditAttribution: erikwebb commentedI use it frequently for performance tuning. I'm actually working on a benchmarking module (sandbox) that can be used to log the individual performance of Views - http://drupal.org/sandbox/erikwebb/1812092
Using something like XHProf or XDebug Profiler, it is often difficult to figure out exactly which View is the culprit. We need these metrics to make sure that we can differentiate the performance of specific Views.
Comment #10
dawehnerI see the point totally, but in theory your module could use the views hooks to start/end some timing on the view object.
It seems to be that you vote against removing this part out of the actual executing of a view, maybe we should make it optional?
Comment #11
erikwebb CreditAttribution: erikwebb commentedI would argue that it should be optional (and disabled by default, like now), but I wouldn't want to remove those statistics from the core Views module.
I agree that my implementation can be done in a different way, so I'm fine with this approach being outdated in the next release.
Comment #12
xjmComment #13
kim.pepperThis appears to already be before hook_views_post_build() in D8.
\Drupal\views\ViewExecutable line #1195:
Comment #14
dawehnerI guess the "render time" is now pretty much fucked up on Drupal 8, given that the actual rendering happens late via render API, so its kinda hard to measure it, especially once
we move more and more into post_render_callbacks and what not.
Comment #15
arihantjn53 CreditAttribution: arihantjn53 as a volunteer commentedWorking on the backport to version 7.x
Comment #16
arihantjn53 CreditAttribution: arihantjn53 commentedComment #17
dhrjgpt2005@gmail.com CreditAttribution: dhrjgpt2005@gmail.com as a volunteer commentedWorking on the backport to version 7.x
Comment #18
dawehner@dhrjgpt2005
You don't have this, this was committed to 7.x-3.x already.
This issue is about porting the patch to 8.0.x
Comment #19
dhrjgpt2005@gmail.com CreditAttribution: dhrjgpt2005@gmail.com as a volunteer commented@dawehner Could i go ahead with the porting the patch to 8.0.x ?
Comment #20
dhrjgpt2005@gmail.com CreditAttribution: dhrjgpt2005@gmail.com as a volunteer commented@dawehner Could you please help me on this. As i am new to this community and would like to be a part to community?
Comment #23
catchComment #25
dhrjgpt2005@gmail.com CreditAttribution: dhrjgpt2005@gmail.com as a volunteer commented@dawehner it seems that the patch is already there in 8.3.x, with $this->build_time is already there. Please suggest if we still need this.
Comment #26
dhrjgpt2005@gmail.com CreditAttribution: dhrjgpt2005@gmail.com as a volunteer commentedComment #27
dawehnerOh yeah that should be fine now. we apply this now inside
\Drupal\views_ui\ViewUI
.Thank you for bringing this up.