If you search on intranet for biblios that have in total thousands of items then then the search result will load very very slowly. The slowing down is linear with the amount of items in the bibs. I already tracked this down to a GetAuthorisedValueDesc() call in C4/XSLT.pm. I will start working on a patch for this.
A quick and (hopefully) efficient change would be to replace the SELECT from authorised_values by a call to C4::Koha::GetAuthorisedValues (the cache is used there).
Because I am working with "Bug 24027" and also search/list is slow on slow machines as well, I can took over this replacement, > and (hopefully) efficient including testing for is it "hopefully", i.e. gives a boost, @Joonas, should I?
(In reply to Jonathan Druart from comment #1) > A quick and (hopefully) efficient change would be to replace the SELECT from > authorised_values by a call to C4::Koha::GetAuthorisedValues (the cache is > used there). This does indeed improve search speed quite a bit. Tested this in test environment where biblios usually have from ten to thousand items and in most cases search time was halved. I think this change along side with syspref introduced in bug 28373 would be a good start to make search work faster.
Created attachment 122275 [details] [review] Bug 23035: Use GetAuthorisedValues in transformMARCXML4XSLT Intranet search is slow if thousands of items are in the biblios shown in the search results. Using GetAuthorisedValues (which uses cache) instead of GetAuthorisedValueDesc in transformMARCXML4XSLT significantly speeds up search time. To test: 1. Add biblio or biblios with hundreds/thousands items. 2. Tab F12 and select 'Network' to view time spent on search. 3. Perform search, note how long search takes to finnish. 4. Apply patch. 5. Repeat search. => Note that search should now work faster. Also prove t/db_dependent/XSLT.t Sponsored-by: Koha-Suomi Oy
GetAuthorisedValues returns an array, GetAuthorisedValueDesc returns a single value, so the patch needs a bit more. To avoid caching/validation issues I proposed a solution on 28371 - can you take a look there?
*** This bug has been marked as a duplicate of bug 28371 ***