BTW, the variant below excluded 75% of the non-leap years with just one comparison: ``` return (year & 0x3) == 0 && ((year & 0xF) == 0 || year % 100 != 0) ```
________________________________________ From: Memory <[email protected]> Sent: Sunday, December 14, 2025 18:23 To: Raffaello Giulietti Cc: [email protected] Subject: [External] : Re: Question about potential optimization for Year.isLeap() 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]<mailto:[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<https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java*L321__;Iw!!ACWV5N9M2RV99hQ!ILBGqbgmHKbXqqdQShgtaBhShlZKl8_Pe_pvHC1yFBjQp2pUZrgcTzDZP6efKRPT8iVsh9IrxVmyRfl8LtnSiu_w$>) ________________________________________ From: core-libs-dev <[email protected]<mailto:[email protected]>> on behalf of Memory <[email protected]<mailto:[email protected]>> Sent: Sunday, December 14, 2025 09:45 To: [email protected]<mailto:[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
