Added a Twig profiler#13428
Conversation
|
Very much looking forward to having this in Drupal 8! (Via https://www.drupal.org/project/webprofiler .) |
There was a problem hiding this comment.
shouldn't this use lateCollect to take into account templates rendered later (in a streamed response for instance) ?
There was a problem hiding this comment.
I went back and forth on this one, but the current version is probably fine with the late data collector.
There was a problem hiding this comment.
this service is only meant to be accessed by twig.extension.profiler and data_collector.twig. It does not need to be retrieved dynamically. Right ? If yes, it could be marked private
There was a problem hiding this comment.
I made public because you might want to get the profile from a CLI tool or something else. It is available through the data collector, but exposing it directly seems like a better idea.
There was a problem hiding this comment.
fine with me (making it private would not allow inlining it anyway, as it is referenced twice)
|
the composer.json of the TwigBridge needs to be updated to Twig |
There was a problem hiding this comment.
should it really be tied to the presence of debug.stopwatch (which is optional in the service definition already) ? this would prevent getting the Twig profiling data when you don't have the Stopwatch
15a1815 to
9c621b6
Compare
|
Oh yeah! This feature is very welcomed! Really nice to have. |
There was a problem hiding this comment.
IMO, it's weird to call a getter before reading a property wich seem to not be related to the previous call
What's about
public function getComputedData($key)
{
if (null === $this->computed ) {
$this->computed = $this->computeData($this->getProfile());
}
return $this->computed[$key];
}
|
👍 ! Really great ! |
|
quick idea: would be nice to dump template context vars also. allows me to provide ide completion. |
|
👍 |
This PR was merged into the 1.17-dev branch.
Discussion
----------
added a profiler
This profiler allows to better understand what's going on when rendering templates. It should be used when debug is true only as it adds some overhead.
Here is a sample output in the text format:
```
main 567.04ms/100%
└ index 463.28ms/82%
└ base 463.24ms/82%
└ base::block(header)
└ index::block(content) 306.29ms/54%
│ └ included 50.18ms/9%
│ └ included 45.42ms/8%
│ └ included 35.42ms/6%
│ └ base::block(content) 104.97ms/19%
│ │ └ included 34.90ms/6%
│ └ included 35.84ms/6%
└ base::block(footer) 156.84ms/28%
└ included 38.96ms/7%
└ base::macro(foo)
```
You can also dump a profile in a Blackfire compatible format to [visualise the data as a graph](http://goo.gl/RwNGFH).
A profile is also a great way to be able to list all templates/blocks/macros that were used when rendering a template.
A PR on Symfony (symfony/symfony#13428) integrates this profiler in the Symfony web profiler to replace the current TimedTwigEngine and to add a new Twig panel.

Commits
-------
4408caa added a profiler
This PR integrates the new Twig 1.18 Profiler (see twigphp/Twig#1597) into Symfony (replace the current TimedTwigEngine) and adds a new Twig panel.
The timers are now available for all rendered templates (TimedTwigEngine was only able to get information from a few of them -- mainly the first template only).
The Twig panel gives you a lot of information about the execution of the templates, including a call graph.