On Sat, 4 Nov 2023 04:57:11 GMT, Quan Anh Mai <qa...@openjdk.org> wrote:
>> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Apply similar optimization to GregorianCalendar, sun.util.calendar > > src/java.base/share/classes/java/time/Year.java line 321: > >> 319: // So for a year that's divisible by 4, checking that it's also >> divisible by 16 >> 320: // is sufficient to determine it must be a leap year. >> 321: return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && >> year % 100 != 0; > > I think `(year & 3) == 0 && ((year & 15) == 0) || (year % 25) != 0` would be > better simply because the common path will be a little bit shorter. Benchmark Mode Cnt Score Error Units LeapYearBench.isLeapYear thrpt 15 0,735 ± 0,004 ops/us LeapYearBench.isLeapYearChrono thrpt 15 0,734 ± 0,006 ops/us So equal to or even slightly worse than baseline. I tested a few variants before submitting the PR - some that looked simpler or better - but the ternary variant in this PR always came out on top. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16491#discussion_r1382422589
