https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38181 --- Comment #23 from Lucas Gass (lukeg) <lucas@bywatersolutions.com> --- (In reply to David Cook from comment #16)
I have been meaning to address search result slowness for a while... but I've got quite a few things on my plate at the moment.
I'm going to keep this one on my TODO list, and I hope to come back to it soon.
If you are a coder, go to C4/XSLT.pm sub buildKohaItemsNamespace, and look at those 3 method calls:
311 elsif ( $item->has_pending_hold ) { 312 $status = 'other'; 313 $substatus = 'Pending hold'; 314 } 315 elsif ( $item->holds->waiting->count ) { 316 $status = 'other'; 317 $substatus = 'Hold waiting'; 318 } 319 elsif ($item->get_transfer) { 320 $status = 'other'; 321 $substatus = 'In transit'; 322 }
If you can optimize those, that should help a lot.
If someone else than me can do this work, that would be awesome.
If not, I do plan to come back to it when I can...
I can confirm that is does seem to buildKohaItemsNamespace that is causing a bottleneck. I added OPACXSLTResultsDisplay to this check: 212 # grab the XML, run it through our stylesheet, push it out to the browser 213 my $itemsxml; 214 if ( $xslsyspref eq "OPACXSLTDetailsDisplay" 215 || $xslsyspref eq "XSLTDetailsDisplay" 216 || $xslsyspref eq "XSLTResultsDisplay" ) And it quite fast. I imagine we must run items throufh buildKohaItemsNamespace to deal with OPACHiddenItems. This certainly does seem like our bottleneck. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.