Skip to content
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

Open
devmes opened this issue Aug 1, 2024 · 1 comment
Open

Slug generation very slow. #809

devmes opened this issue Aug 1, 2024 · 1 comment

Comments

@devmes
Copy link

devmes commented Aug 1, 2024

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

@lochmueller
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants