Welcome!

Apache Authors: Eric Brown, Jayaram Krishnaswamy, Yeshim Deniz, Bob Gourley, Si Chen

Related Topics: Open Source, Eclipse, Web 2.0, Apache, CMS

Open Source: Blog Post

Drupal 8: A View into Performance

Part 4 in a 5-part series on performance in the upcoming Drupal 8

This is part 4 in a 5-part series on performance in the upcoming Drupal 8. Check out part 3, on performance in Twig templating, here.

Views is one of the most installed Drupal modules with over two thirds of Drupal sites reporting that they have it installed. Soon, though, that number will go up: as of Drupal 8, Views is a core module! This effort started as a community effort and was announced as an official Drupal 8 initiative in a post by Dries explaining why this change is so exciting.

One of the reasons that Views is so popular is that it provides an ‘all-in-one' answer without writing a single line of code. But there's a reason that many programmers hate WYSIWYG editors: you see the result, but not the steps taken to produce it, and what you don't know might come back to bite you. While a WYSIWYG editor will get you broken links or weird formatting, WYSIWYG data retrieval can have direct performance implications. A'straightforward' View might fetch data in unexpected ways, and even ‘small' changes like adding a node relationship can result in radically different queries. Worse, any scalability issues may only manifest when a View is run against production-like data. A View focusing on user content might start choking on a user who favorites hundreds of nodes instead of the five you tested with.

That's not to say that there's anything wrong with Views, as this problem is very common in ORMs in frameworks such as Django and Rails. In fact, because Views is more all-encompassing, it provides effective out-of-the-box solutions to some of these problems in the form of result, block, and page caching. However, Views aren't cached by default, and even with Devel integration it provides minimal data on its performance.

Rather than using a profiler or debugger, it's possible to monitor Views performance by integrating with its code. Structurally, Views can be broken down into a ‘build-execute-render' pipeline. In Drupal 7, many hooks are available for interacting with this process and changing how Views are constructed. There have been many Views API changes over time, but this basic set of hooks can be used on Drupal 6 and 7 sites, and Drupal 8 continues that trend. The TraceView Drupal module implements these hooks to track time spent in Views:

The Views rendering step takes less time in Drupal 8 than in Drupal 7 because it is no longer responsible for generating HTML.

The Views rendering step takes less time in Drupal 8 than in Drupal 7 because it is no longer responsible for generating HTML.

Examining identical Views in Drupal 7 and 8 reveals that less time is spent in the render step of the pipeline. The codebase has been extensively refactored, so comparing backtraces would be difficult, but I've already examined this discrepancy using TraceView in my last article about Twig, the new templating engine in Drupal 8. The Views pipeline still exists in Drupal 8, but the render step no longer generates the View's HTML, meaning that the performance of a View has to be placed in the context of the rest of the request.

When I wrote about Twig, though, I didn't cover more advanced use cases for Views. There are often multiple Views on a page, or sometimes even multiple displays from the same View. To compare how this works in Drupal 7 vs. Drupal 8, I made identical setups by creating nodes with Devel Generate, enabling the Archive and Recent Comments Views, and placing their blocks in a sidebar. Here are traces generated by visiting the full page version of the Archive:

A request to Drupal 7, with a segment of time spent in Views highlighted in white.

A request to Drupal 7, with a segment of time spent in Views highlighted in white.

A request to the same configuration in Drupal 8, again with a portion of Views time highlighted in white. Drupal 8 performs much more initialization work before entering Views, and Twig rendering and cache setting afterwards.

A request to the same configuration in Drupal 8, again with a portion of Views time highlighted in white. Drupal 8 performs much more initialization work before entering Views, and Twig rendering and cache setting afterwards.

More Stories By James Meickle

James started as a hobbyist web developer, even though his academic background is in social psychology and political science. Lately his interests as a professional Drupal developer have migrated towards performance, security, and automation. His favorite languages is Python, his favorite editor is Sublime, and his favorite game is Dwarf Fortress.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.