https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16221
--- Comment #3 from Jacek Ablewicz <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
