[Koha-bugs] [Bug 31216] inventory.pl is slow when comparing many barcodes

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31216

--- Comment #5 from David Cook <dcook at prosentient.com.au> ---
In bug 33989, I moved the AV description code into the "additemtoresults"
function, because it was running the AV lookup for items that were *not*
displayed. By making this change, I was vastly improving my inventory run times
(e.g. taking 30 seconds instead of 60 seconds). 

I've just tried with and without selecting "Compare barcodes list to results",
and I notice that even with it selected you don't end up displaying many
results, so bug 33989 should take care of  a lot.

--

Of course, when writing bug 33989, I thought that I should add more caching,
but  as Fridolin mentions Koha::AuthorisedValues->get_description_by_koha_field
appears to already use caching (since 2016). 

But... if the caching were working correctly... then I probably shouldn't have
noticed such an improvement on bug 33989...

I added some debugging code, and it turns out...
Koha::AuthorisedValues->get_description_by_koha_field() doesn't cache null
descriptions. Let me explain...

Consider a cache key for a Default framework notforloan with a value of 0: 
AV_descriptions::items.notforloan:0

In k-t-d, the NOT_LOAN AV only has the following values: [-1,1,2,3]

So for the cache key of AV_descriptions::items.notforloan:0, a database lookup
will *always* be performed, and an empty hashref will *always* be returned.

Since 0 is probably the most common value found, at least in k-t-d, you're
looking at *a lot* of database calls for something that should probably be
cached.

Of course, changing Koha::AuthorisedValues->get_description_by_koha_field would
have repercussions throughout a fair bit of Koha. 

But since it's a L1 cache... we really should be caching the empty hashref so
that we're not doing unnecessary database lookups.

-- 
You are receiving this mail because:
You are watching all bug changes.