Hi, Thanks for the correction. I confused the implementations.
I'm proposing to change: ```java return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` to: ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` At the low level, this should be slightly faster because: 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation 2. Better for branch prediction - Simpler control flow pattern 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. Raffaello Giulietti <[email protected]> 于 2025年12月14日周日 19:45写道： > Hi, > > the current logic in mainline is > ``` > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && > year % 100 != 0; > ``` > (see > https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321 > ) > > > ________________________________________ > From: core-libs-dev <[email protected]> on behalf of Memory < > [email protected]> > Sent: Sunday, December 14, 2025 09:45 > To: [email protected] > Subject: Question about potential optimization for Year.isLeap() > > Hello core-libs-dev team, > > My name is Memory2314, and I am a new contributor currently waiting for my > Oracle Contributor Agreement (OCA) to be processed. > > I have been studying the `java.time.Year.isLeap()` method and would like > to propose a micro-optimization: > > **Current logic:** > ```java > return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); > ``` > > **Proposed optimization:** > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > **Key improvements:** > - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` > - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 > - Reduces modulo operations from 3 to 1 in the common case > > **Verification benchmark:** > ```java > public static void main(String[] args) { > int[] years = new int[1_000_000_000]; > Random random = new Random(); > for (int i = 0; i < years.length; i++) { > years[i] = 1970 + random.nextInt(5000 - 1970 + 1); > } > > long start1 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOriginal(year); > } > System.out.println("Original: " + (System.currentTimeMillis()-start1) > + "ms"); > > long start2 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOptimized(year); > } > System.out.println("Optimized: " + (System.currentTimeMillis()-start2) > + "ms"); > } > > public static boolean isLeapOriginal(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % > 100 != 0; > } > > public static boolean isLeapOptimized(long year) { > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > } > ``` > > **Correctness verification:** I've tested this logic extensively, > including edge cases like year 0, negative years (proleptic Gregorian), and > all century boundaries from -10,000 to 10,000. > > I am aware that I cannot submit a formal patch until my OCA is complete. > However, I would be very grateful for your initial technical feedback on > this approach before I proceed to create a fully tested patch with > benchmarks. > > Once my OCA is in place, would there be a maintainer or an experienced > contributor interested in sponsoring this change if it proves worthwhile? > > Thank you for your time and consideration. > > Best regards, > Memory2314 >
