~adj/comment-test-tracker#126: 
Refactor main + improve startup performance

Main.java, once over 10,000 lines, was shrunk to about 2000 years ago, but has grown to 3500 since then. I've been noticing its unwieldiness, so it's time to refactor it.

While I'm at it, it's worth seeing if refactoring can improve startup times. They aren't instant currently, even on my 4 GHz Core i5 2500k.

Status
REPORTED
Submitter
bitbucket:QuintillusCFC
Assigned to
No-one
Submitted
6 years ago
Updated
4 years ago
Labels
No labels applied.

~adj 4 years ago

So far, have refactored/removed about 500 lines of code, around menus and file IO. This shrinks the footprint notably.

Have also optimized some menu initialization, and file chooser creation. This has had a significant different in the IDE (mid-300s to about 200 ms), with Java 8 Update 151, but outside of the IDE, with Java 9 Update 4, the difference is more mild. Averaging five starts, 1.19 took 364 ms; the updated version takes 304 ms. That's still a one-sixth improvement, which is good, but it's not at the point of being noticeable to the eye. At least on this machine. On a notably slower one, it might be.

There's certainly still opportunity in those two areas alone, however.

~adj 4 years ago

Optimizing font-setting is another one that did better in the IDE than when done. Saved 30 ms in the IDE; saved 10 ms outside the IDE (though it held up with the five-start average). Maybe Java 8 is better-optimized than Java 9? At any rate, 294 vs 364 means I'm now at a 19% improvement, almost one-fifth.

~adj 4 years ago

Ran the same startup test on 1.10; it averages 262 ms. So things have become slower lately. My guess is the helpful information on the start screen in 1.19 is the cause of it.

Test results (all release build, JDK 9.04; Core i5 2500k @ 4 GHz):

#!Core i5

0.67: 240 ms
0.70: 182 ms
0.80: 220 ms
0.90: 222 ms
1.00: 241 ms
1.10: 262 ms
1.15: 277 ms
1.17: 344 ms
1.18: 320 ms
1.19: 364 ms
1.20 (in-progress): 304 ms

0.67 is the first version that kept track of startup time; the commit message says it reduced startup time by about 2/3. It appears there were further optimizations not long thereafter, but there's a clear trend towards longer startup times after that. And while recent changes have made it worse, there were gradual performance regressions before that, too.

~adj 4 years ago

Also, there's a comment saying that main.setVisible(true) takes 140 ms all by itself. That was from before I built my desktop, and it's 65 ms when I time it now - but there is a large fixed cost there.

So right now we have (times from within the IDE, which is faster):

0 - 30: static initializer 30 - 33: public static void main 33 - 113: Unspecified 113 - 175: Constructor 175 - 218: Visibility

I believe the "Unspecified" is variable initialization... although super constructor (JFrame) could be part of it too. There are literally hundreds of lines of variable initialization, though, so I could see that being a significant chunk of it.

~adj 4 years ago

OK, added a dummy class whose entire purpose is to log a log statement when it's initialized. But it lets you get logs of how long it takes to initialize variables, by initializing it a few times.

Confirmed that the 80 ms or so is variable initialization. And the lion's share of it is creating the CustomMapSetupForm. Which is unexpected. This is used to create a new custom map... and is rarely used. It has some reflection, and does some Swing packing, but I don't see an obvious reason for why it's by far the slowest. Perhaps it does some Swing initialization stuff as the first GUI Swing component, and that slows it down?

~adj 4 years ago

I think the Swing init theory is on track. Removing the CustomMapSetupForm's initialization got us to the constructor much quicker... but doesn't seem to get the proggie started quicker. And indeed, in the compiled version, it took us from 304 ms to 294 ms - much closer to what I'd expect from removing one (somewhat complex) form.

Thus my suspicion now is that an accumulation of small improvements, rather than one or two big ones, will account for the potential remaining performance improvements.

Register here or Log in to comment, or comment via email.