-
-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slug generation very slow. #809
Comments
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 :-/ 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, |
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
The text was updated successfully, but these errors were encountered: