https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16140
--- Comment #17 from Jesse Weaver <[email protected]> --- 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. _______________________________________________ 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/
