Epic #89759: Performance improvements in Forms module
Optimize form listing
Currently forms are retrieved as follows in exactly this order:
- Traverse all configured storage folders
- Collect all
*.yamlfiles in a folder
- Read the full content of each
- Determine if the content looks like a form definition
- Skip anything which does not end with
There is clearly room to improve on each step and especially the order could be changed to have simple filters (like for
.form.yaml) executed early using custom FAL filters.
Updated by Sybille Peters over 3 years ago
Is it really necessary to have the forms anywhere in the configured storages? Or is it possible to have them in a dedicated place?
Also, does 1. mean the storage is searched? Not just sys_file?
Should you even have files that can be connected to content elements and are scanned and referenced by FAL and forms in one place?
Scanning the entire storage seems a bit much.
I have not used form for a while, but the first time I used it, there were also performance problems with upgrade wizards because the wizard would can the entire storage.
There are a number of open issues related to large sites (in general, not specific to form). Some of these do not turn up as problems in a typical small installation. But they can start to make TYPO3 unusable when you get to a certain point of number of files, dirs, pages etc. (e.g. see pagetree performance, see #52374, #88873 etc.)
My wish is that the possible performance impact is considered early and the patches are already tested keeping these scenarios in mind.
Maybe this is too much to ask.
But then I think a limit should be defined of max number of pages, files, dirs etc for TYPO3.