Bug 7073 - GetCOinSBiblio should take $record, not $biblionumber
Summary: GetCOinSBiblio should take $record, not $biblionumber
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: 3.8
Hardware: All All
: PATCH-Sent (DO NOT USE) enhancement (vote)
Assignee: Ian Walls
QA Contact: Marcel de Rooy
URL:
Keywords:
Depends on:
Blocks: 5729
  Show dependency treegraph
 
Reported: 2011-10-20 19:48 UTC by Ian Walls
Modified: 2013-12-05 20:04 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed Patch (4.20 KB, patch)
2011-10-20 20:11 UTC, Ian Walls
Details | Diff | Splinter Review
Bug 7073: GetCOinSBiblio should take $record object, not biblionumber (4.25 KB, patch)
2011-11-04 02:54 UTC, Chris Cormack
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Walls 2011-10-20 19:48:33 UTC
GetCOinSBiblio is summoned three places in Koha so far:  C4::VirtualShelves/Page.pm, opac/opac-search.pl and opac/opac-detail.pl.  It takes in a biblionumber, then immediately calls GetMarcBiblio on that to get the record.  This is a very expensive call.

The kicker is that in 2 of the 3 contexts, we've ALREADY GOT the $record.  We're pulling it in twice per title, and the number of titles we loop through is either OPACnumsearchresults or numsearchresults.  The default of 20 has us making 40 calls to GetMarcBiblio... at several dozen milliseconds per call, that's a lot of time!

If we change the GetCOinSBbiblio routine to take in a $record object instead, we save those calls on Lists and opac/opac-detail.pl.  We'd just need to call GetMarcBiblio in the search results before calling GetCOinSBiblio... which is just moving the call from inside the subroutine to outside (no performance loss).

Patch forthcoming.
Comment 1 Ian Walls 2011-10-20 20:11:10 UTC Comment hidden (obsolete)
Comment 2 Paul Poulain 2011-10-24 11:38:19 UTC
Updating Version : This ENH will be for Koha 3.8
Comment 3 Paul Poulain 2011-10-25 15:05:56 UTC
Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)
Comment 4 Chris Cormack 2011-11-04 02:54:00 UTC
Created attachment 6174 [details] [review]
Bug 7073: GetCOinSBiblio should take $record object, not biblionumber

This patch changes the GetCOinsBiblio subroutine to take a MARC record object
(as returned from GetMarcBiblio) instead of a biblionumber.  The first thing the subroutine
did was GetMarcBiblio, and the $biblionumber passed was never used again.

This subroutine was only used 3 places: opac/opac-search.pl, opac/opac-detail.pl,
and C4/VirtualShelves/Page.pm.  In the first and last cases, it was used in a loop.
In the last two cases, a call to GetMarcBiblio had already been done.  This is expensive, and
we were doing it twice per record.

For opac/opac-search.pl, the call to GetMarcBiblio was moved to just outside GetCOinSBiblio;
this will not change the performance at all.  But for opac/opac-detail.pl and C4/VirtualShelves/Page.pm,
a redudant call to GetMarcBiblio is now avoided.

To Test:
1. Enable COinSinOPACResults in system preferences.  Perform a search in the OPAC.
   Verify that the COinS spans are showing up
2. View the detail record of one of the returned items.  Confirm that the COinS span exists on the detail page.
3. View a list in the OPAC.  Confirm that COinS spans are still showing up

Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Comment 5 Ian Walls 2011-11-19 23:50:47 UTC
Assigning to M. de Rooy for QA
Comment 6 Marcel de Rooy 2011-11-23 14:54:10 UTC
QA: Code looks good. Should benefit performance. Well documented.
Comment 7 Paul Poulain 2011-11-24 10:45:15 UTC
I checked with a grep that there were no other calls to GetCOinSBiblio, that's the case.

Patch pushed, please test.
Comment 8 Jared Camins-Esakov 2012-12-31 00:19:27 UTC
There have been no further reports of problems so I am marking this bug resolved.