The most promising result in terms of performance improvement is the TypoScript Content Cache
for Neos. It is a content cache with nesting support integrated into TypoScript. That means that cache identifiers and tags for flushing can be configured in TypoScript and rendered content will be re-used across documents. If an inner cache entry is flushed, the entry will be re-created as lazy as possible (no need for a complete document re-render). This not only results in the highest possible speedup (first measurements in the demo site show response times < 80ms in Production, further improved by skipping routing and controller invocation with an HTTP component) but also means that caching can be active during editing without side effects (and of course it supports workspaces). The change is still under review
now has an in-memory first level cache for Nodes, eliminating queries to the ORM for nodes that have already been fetched.
The FlowQuery "children" operation will now optimize some common filters internally to reduce the amount of nodes fetched and to produce better queries.
The Menu implementation
was improved and now correctly calculates item states alongside some new features (see change
While the use of ExtJS was dropped long ago, Neos was still using Ext.Direct
for communication with the server. The removal of that dependency was on the agenda for a long time now. During the code sprint we managed to have a replacement change ready for review
. It is a start on further optimizations to implement a RESTful API in Neos.
The site export
in Neos works quite fast even for huge sites, but importing is slowing down to a crawl for a lot of nodes. This is improved by directly talking to the database without involving the ORM layer. The change is still under review review.typo3.org/27386
(and right now would break importing for PostgreSQL users due to a PHP bug
Not really performance related is the support for content dimensions
. We decided to work on it anyway, as it changes a lot in the internals of TYPO3CR - and further performance improvements are easier to be based on the new code. Another result of working on content dimensions during the performance sprint was that even though there is a lot of new code and complexity involved, there is almost no performance penalty coming with the new feature. Focus FTW!