Skip to content

Small splash startup optimization - #9677

Open
mbien wants to merge 1 commit into
apache:masterfrom
mbien:tiny-startup-splash-optimization
Open

mbien wants to merge 1 commit into
apache:masterfrom
mbien:tiny-startup-splash-optimization

Conversation

@mbien

@mbien mbien commented Oct 7, 2026 •

Copy link
Copy Markdown
Member

reduce early startup EDT usage by updating the splash only once every 50ms.

  • 15-40ms less EDT usage.(might be more, depends on how repaint() works)
  • 70ms less main thread usage blocking on invokeLater() (surprisingly expensive)

(measured with all clusters active after a few warmup runs)

delayed followup to #9303

reduce early startup EDT usage by updating the splash only once every
50ms.

 - 15-40ms less EDT usage.
 - 70ms less main thread usage blocking on invokeLater()
@mbien mbien added this to the NB32 milestone Oct 7, 2026
@mbien mbien added performance Platform [ci] enable platform tests (platform/*) UI User Interface ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) labels Oct 7, 2026
@mbien mbien changed the title Small splash optimization Small splash startup optimization Oct 7, 2026
} catch (IllegalStateException splashAlreadyClosed) {}
next = System.currentTimeMillis() + 200;
}
paint();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC we don't reach this code in practice any more - comp is never null?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the original logic (which was left in tact when splash was moved to the EDT in #9303) is still in place.

setRunning() checks if getSplashScreen() returns something, if it does it initializes a different painter while leaving comp null. So this branch is still theoretically reachable when the splash launcher flag is used. It still exists in the windows launcher AFAIR. I remember testing this with two splash pngs, one was green one was blue - probably a comment somewhere on the original PR.

Also: i think setRunning(false) should also set comp to null but I probably didn't do that since the getter is public - this could cause an NPE somewhere.

@neilcsmith-net neilcsmith-net Oct 8, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, if you manually create the splash file it might trigger, but the code to actually generate that file doesn't run since #1246 So, in practice this timing code using next is not used in the current release.

That wasn't an argument against your approach, or in favour of removing the comp == null code. Just a useful note to consider in reviewing what has actually changed here during startup.

@neilcsmith-net neilcsmith-net left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good. I don't think we ever hit the timed code in repaint any more.

Could possibly just use a Swing Timer to drive repaints and not use invokeLater at all if it's a concern?

@mbien

mbien commented Oct 7, 2026

Copy link
Copy Markdown
Member Author

i considered a timer but this seemed easier since the code was already there, it was just moved outside of the EDT call

@neilcsmith-net

Copy link
Copy Markdown
Member

Sure, that's fine, just the existing timing code is (should) never be hit anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) performance Platform [ci] enable platform tests (platform/*) UI User Interface

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants