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.

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 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.

• What Google thinks SOA is
• Research and Markets: A View into VMware View 3
• Verizon Launches New Site that Gives Hispanics an Inside View into the FiOS Experience