[Koha-bugs] [Bug 16221] Use Storable::dclone() instead of Clone::clone() for L1 cache deep-copying mode

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Fri Apr 8 12:46:50 CEST 2016


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

--- Comment #3 from Jacek Ablewicz <abl at biblos.pk.edu.pl> ---
(In reply to Jonathan Druart from comment #2)
> Jacek,
> Bug 16166 looks fine by me. Are you suggesting to drop it?

No, not necessarily anyway.

I just thought that it would be interesting to find out what are the exact
causes of the speed improvements Bug 16166 provides: 1) different cloning
method or 2) cache architectural changes. Turns out, both 1) and 2) are
beneficial performance-wise, but 1) is much bigger factor.

I still think Bug 16166 may be a better solution, especially in the long term.
When applied on top of Bug 16221, it would improve cache speed somehow further,
and it provides one additional important feature (separating "safe" and
"unsafe" cache fetches, so they don't interfere with each other). Note that
after Bug 16044, cache fetches are NOT safe in the current master - even if
there are no "unsafe => 1" parameters used anywhere in the code currently,
because issue 1) mentioned in Bug 16044 comment #20 wasn't resolved before
16044 got to master (unless I'm very much mistaken ?).

Trouble with Bug 16166 is that it's one of those architectural changes which
are pretty much untestable in any conventional way, and it's not easy to
predict what kinds of regressions it may introduce (if any) just by looking at
that code. Also, Bug 16166 is a bit of a mess right now, I guess I shoud at
least squash patches #1 - #3 to make it more readable.

Bug 16221, OTOH, is a trivial follow-up of Bug 16044, it does improve caching
performance substantially, and risks that it may cause some regressions are
close to nil.

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


More information about the Koha-bugs mailing list