ghost
commented
8 years ago After digging deeper into the problem, I found the reason inside the yag ImageViewhelper.
In the default theme partial of yag (Resources/Private/Partials/Album/AlbumThumb.html), the attribute resolutionName is set to "albumThumb".
This is the reason why this code inside the viewhelper is called:
$resolutionConfig = $this->resolutionConfigCollection = Tx_Yag_Domain_Configuration_ConfigurationBuilderFactory::getInstance() ->buildThemeConfiguration() ->getResolutionConfigCollection() ->getResolutionConfig(trim($this->arguments['resolutionName']));
I don't know why, but this call needs very very long.
If I remove the albumThumb-attribute in the partial and add a width="200" instead, everything works fine.
I use yag to generate a list of about 21 albums containing each about 20 pictures.
Every time when logged into the backend and try to open the overview page (in frontend) containing the list of albums, it takes several minutes (!) until the page is loaded. http://www.jugend-debattiert.de/service/presse/bildmaterial-aktuell/
The problem is reproducible on several systems (php 5.4, php 5.5, php 7.0, TYPO3 6.2, TYPO3 7.6)
After profiling the script using php blackfire, I identify the main time (3.3s of 4.6 on this system) in about 11.000 calls of the TYPO3\CMS\Extbase\Persistence\Generic\Mapper\DataMapper::map method.
The problem persists, if I e.g. disable 19 of the 21 albums in the yag backend module.
I suppose the reason for this problem is extbase, which tries to map all properties of all items of all albums.
Maybe it would be a idea to use a simplified "context" model for generating the album list, which does not contain the relationships to there images?