During the 8.x cycle we've introduced several known performance regressions compared to Drupal 7, which we need to resolve before release so that Drupal 8 isn't slower than Drupal 7.
This doesn't mean every single regression needs to be individually optimized away - in some cases it might be necessary to do that, or trying to micro-optimize it won't be worth the extra effort.
However there are places where we've introduced something with the intention that it will allow us to make performance or scalability enhancements elsewhere (like blocks as sub-requests for example), and introducing the performance regression without getting the nice performance feature at the end of it puts us in a not very happy place.
Opening this as a meta-issue to try to track those regressions as they get committed, along with the issues that are attempting to resolve them - making this a critical task since I'm not prepared to release Drupal 8 with obvious performance regressions compared to Drupal 7, it was bad enough from 6 to 7 and we shouldn't do that again.
Criteria for critical performance issues
A performance issue is critical by itself if some of the following are true:
- There is concrete performance issue identified by profiling (MySQL, PHP or browser equivalent) and a viable plan to resolve it
- It can't be committed to a patch-level version (8.0.0 => 8.0.1)
- Over ~100ms or more savings with cold caches and would have to be deferred to a minor version
- Over ~10ms savings with warm caches and would have to be deferred to 9.x
- Over ~1ms or more with the internal page cache and would have to be deferred to 9.x
- Gets measurably worse with lots of contrib modules or large data sets (e.g. non-indexed queries) and would have to be deferred to a minor version
- Other specific issues at branch maintainer discretion
For up-to-date information on work being done on performance and caching, see the Drupal 8 performance issue spreadsheet.
High priority issues
Several new core APIs have lost optimizations from Drupal 7 and earlier where multiple objects could be loaded with a single request from the database/cache (i.e. compare CMI to variable_init()), the following issues attempt to add some kind of multiple load/pre-loading/CacheCollector support to those systems:
Plugin discovery caching:
Block context discovery:
As a generic performance improvement, there is also a focus on enabling render caching by default for all entities, this is being tracked in the D8 cacheability tag:
Other general performance issues
Use the Performance tag to find any other performance issues. Filtering by 'critical' or 'major' should find the most serious ones.
Original issues where some of the more serious regressions were originally committed
This is an incomplete list, but it would be useful to track specific commits that made performance worse - feel free to add them here. However a lot of performance issues are introduced by new APIs and only become measurable as core is converted to the new API and backwards compatibility layers removed...
(the minimum lifetime removal and also )