[Koha-bugs] [Bug 16140] Only clear L1 cache when needed

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

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

--- Comment #17 from Jesse Weaver <jweaver at bywatersolutions.com> ---
I'm starting to think there's something very oddly system dependent here.

Running the same tests (each number inside the parentheses is the total runtime
of 10 runs of Jonathan's tests, and the number of front is the total of those
totals):

master (6a04ba598, which includes the last batch on bug 16044 to set the L1
cache more often):
232.81 (22.93+23.21+23.21+23.07+23.41+23.01+23.51+23.25+23.51+23.70)

master + 16088:
441.07 (43.28+43.87+44.00+43.90+44.35+44.54+44.96+44.53+43.92+43.72)
# I suspect this is because L1 cache hits, and thus deep-cloning, is increased.

master + 16088 + the second patch here (don't clone framework/authvals):
137.90 (13.28+13.81+14.02+13.79+13.81+13.32+13.96+14.00+13.95+13.96)

master + 16140 - intelligent flushing:
233.67 (23.61+23.02+23.48+23.64+22.98+23.62+23.44+23.54+23.60+22.74)

master + 16140:
137.34 (13.92+13.90+13.75+13.70+13.42+13.84+13.93+13.74+13.83+13.3

master + 16140 + 16088 - intelligent flushing:
139.33 (14.03+14.03+13.96+14.06+13.60+13.88+13.87+14.02+14.18+13.70)

master + 16140 + 16088:
134.67 (13.40+13.33+13.52+13.38+14.03+13.43+12.97+13.42+13.59+13.60)


This makes sense to me. Reducing deep cloning makes the biggest difference, and
as we add 16088 then 16140 the number of L1 flushes drops from:
  4200 (100 runs * 21 L1 flushes per request) to
  100 (100 runs * 1 L1 flush per request) to
  1.

I'm currently trying an approach that recursively locks any refs passed to the
L1 cache, but am having trouble making it performant.

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