lochmueller
commented
3 months ago Hey @devmes ,
you are right... the code is not very efficient. The reason would be, if there is an event, with 100 index entries, the slug generation is called for every index. BUT... there is a while loop in the buildSlug function. The first entry will call "isUniqueInTable" once, but the second will call "isUniqueInTable" twice.. and so one. So the 100 index records, call "isUniqueInTable" 5.050x :-/ But the problem is, that this is the core solution.
We could avoid this problem, if we pregenerate the slug entries incl. the counter, so the 100 index entries call "isUniqueInTable" just 100 times, because we solve the problem in front of the "buildSlugForUniqueInTable" call?! So we can fix this (or as "alternative integration" via feature flag) this in the IndexService.
Regards, Tim
devmes
After a migration from an older version to the current one (5.x -> 13.x) (all upgrade wizards executed), calenderize has performance problems when editing data records. When I create a new calendar entry for a data record in the TYPO3 backend, it takes extremely long to save it.
The reason is that if many entries have to be created in the calendar index table, the slug generation for each index data record takes a very long time.
After debugging, i found the problem in the method "Classes/DataHandling/SlugHelper.php -> isUniqueInTable". Here a DB query is generated for each index entry and this is probably the bottleneck.
Does anyone know this problem? Or is it possible to disable the slug generation?
Environment: TYPO3 v12.4.17 calendarize v13.0.7 DB MariaDB PHP 8.2