Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

muC faster start up #1044

Merged
merged 42 commits into from
Apr 23, 2024
Merged

muC faster start up #1044

merged 42 commits into from
Apr 23, 2024

Conversation

pskowronek
Copy link
Member

@pskowronek pskowronek commented Aug 15, 2023

  • tweaked how bundles are being loaded (added parallelized bundle loading and deferring) - this gave 2-3 times faster bundle loading etc (from 2-3s to ~400-800ms)
  • added java params for to start faster: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 - these gave quite a lot of boost (https://stackoverflow.com/a/46516509/1715521)
  • further defer Bonjour loading (let JmDNSImpl start later to let muC have resources for start up)
  • muCommander.java - parallelized loading of configurations
  • replaced all imports swing.* and awt.* in java - this gave almost no speed effect
  • SMB activator moved to background (sb needs to check if it works - this never worked for me)
  • theme loader - replaced all ladder IFs with switches (hence code compatibility set to 20) - done automagically by Idea (refactor)
  • enabling Notifications moved to background (as it also took some time)
  • loading icons used .getResource two times
  • LaFs loading was taking long - additional LaFs are being loaded in background (unless they are chosen by the user)
  • Clipboard check is done on start up, sometimes it caused delay if something unsupported by muC was there (like code copied from Idea, this caused 'class not found' exceptions) - to be addressed here: [Bug] Checking clipboard state on startup can delay overall launch time #1137
  • ADB menu deferred, Bonjour init also moved after start
  • Quick list loaded in background
  • Pre-load JFrame and couple of JPanels as early as possible and then use it Application for MainFrame etc
  • Pre-load all fonts into JVM - this is very slow, at least on macs - start loading fonts in background even before felix is initiated (this may yield caching fonts done in a previous commit unnecessary)

Those changes make loading times 2-3 faster (3s->1s on Andreas' mac, on my mac from 6-7s->~2.6-3s).

Remarks:

  • it seems that splash screen loading adds 100-200ms to startup time on my mac (this can be turned off in Preferences)
  • What's left is:
  • the time of loading/initializing JVM - not sure if something could be done about it more (@ahadas )
  • think about loding bundles for extensions/plugins when main app started (akin how Idea or Eclipse does it).

@pskowronek pskowronek requested a review from ahadas as a code owner August 15, 2023 14:31
@ahadas
Copy link
Member

ahadas commented Aug 15, 2023

btw, I've spotted that hamcrest-core bundle is being loaded? Why?

junit drags it:

+--- project :mucommander-protocol-registry
|    +--- project :mucommander-commons-file (*)
|    +--- project :mucommander-commons-util (*)
|    +--- project :mucommander-protocol-api (*)
|    +--- project :mucommander-format-gzip (*)
|    +--- project :mucommander-process (*)
|    +--- project :mucommander-translator (*)
|    +--- org.slf4j:slf4j-api:1.7.36
|    +--- org.osgi:osgi.core:8.0.0
|    +--- org.ovirt.engine.api:sdk:4.4.5
|    |    +--- org.slf4j:slf4j-api:1.7.7 -> 1.7.36
|    |    +--- com.fasterxml.jackson.core:jackson-databind:2.10.0
|    |    |    +--- com.fasterxml.jackson.core:jackson-annotations:2.10.0
|    |    |    \--- com.fasterxml.jackson.core:jackson-core:2.10.0
|    |    +--- org.apache.httpcomponents:httpclient:4.5 (*)
|    |    \--- org.apache.httpcomponents:httpcore:4.4.1
|    \--- com.googlecode.json-simple:json-simple:1.1.1
|         \--- junit:junit:4.10
|              \--- org.hamcrest:hamcrest-core:1.1

@pskowronek
Copy link
Member Author

btw, I've spotted that hamcrest-core bundle is being loaded? Why?

junit drags it:

any hint where to add exclusion?

@pskowronek
Copy link
Member Author

PR updated to address: #492 (comment)

@pskowronek
Copy link
Member Author

PR updated - faster UI start up.

@pskowronek
Copy link
Member Author

@ahadas - this PR is more PoC, but - in one of the recent commits I've switched code compatibility to java 20 - I guess this broke tests here? ./gradlew clean test locally works for me.

@pskowronek
Copy link
Member Author

@ahadas - I tried to commit each attempt/idea in a separate commit. Some ideas were removed in subsequent commits (try & error), but overall I think all commits bring some benefit. Font caching is disputable, however I would keep it (it seems that on my mac it saves ~100ms if/when fonts are pre-loaded on time). Since a lot of concurrency has been introduced it requires a lot of testing on different platforms. From my side, occasionally, 1 time I've spotted a problem when action menu bar was not displayed (right now I cannot reproduce that, but I think there's a race condition), plus rarely I get Cannot invoke "javax.swing.JButton.setToolTipText(String)" because "oneTouchButton" is null.

Nevertheless, tell me what you think about it, should be continue this, or not.

@ahadas
Copy link
Member

ahadas commented Sep 9, 2023

@ahadas - I tried to commit each attempt/idea in a separate commit. Some ideas were removed in subsequent commits (try & error), but overall I think all commits bring some benefit. Font caching is disputable, however I would keep it (it seems that on my mac it saves ~100ms if/when fonts are pre-loaded on time). Since a lot of concurrency has been introduced it requires a lot of testing on different platforms. From my side, occasionally, 1 time I've spotted a problem when action menu bar was not displayed (right now I cannot reproduce that, but I think there's a race condition), plus rarely I get Cannot invoke "javax.swing.JButton.setToolTipText(String)" because "oneTouchButton" is null.

Nevertheless, tell me what you think about it, should be continue this, or not.

@pskowronek thanks for the effort you've put on this! I was not able to follow the changes closely recently but I read your conversation with @Andreas0602 and it seems you've managed to accelerate the startup time nicely. there are quite a few changes here so it can take me some time to review them but as I want to release 1.4.0 soon, I'll try to provide feedback shortly

src/main/java/com/mucommander/main/AutoProcessor.java Outdated Show resolved Hide resolved
var jarPath = jarFile.toURI().toString();
if (jarPath.contains("dropbox") || jarPath.contains("jediterm")
|| jarPath.contains("protocol-gcs") || jarPath.contains("viewer-pdf")
|| jarPath.contains("gdrive")) {
Copy link
Member

Choose a reason for hiding this comment

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

that's not that great.. what's the reason for this?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, it's not, I agree. Those bundles are relatively big and not required as the first ones. We may introduce sth like checking bundle size, and defer the biggest ones.

Copy link
Member

Choose a reason for hiding this comment

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

I'm ok with using several threads to load the bundles but we need to ensure that the protocol and format bundles are loaded before mucommander-core is loaded as we may have an initial location that requires them

Copy link
Member Author

Choose a reason for hiding this comment

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

I may try to drop this deferring and see how it impacts the load time.

Copy link
Member

@ahadas ahadas Apr 20, 2024

Choose a reason for hiding this comment

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

I may try to drop this deferring and see how it impacts the load time.

in my tests, I didn't see an issue with deferring gdrive even when I had my google drive loaded on startup but @pskowronek did you check the above?

@ahadas - I would keep that "deffering", i.e. to start them as the last ones so they have more time to load (these are the biggest jars/bundles). In a couple of minutes I will provide commit - I moved those names to a separate global variable with some explanation.

Turning off 'defer' adds ~200ms delay - these measures were done by running both versions a couple of times. With defer, the quickest load of bundles was around 1.5s on my machine, avg 1.6s, whereas for no-defer version, it was rather 1.8s on avg. Again, this observation might be only relevant on my macbook - maybe on newer macbooks both results might be the same or negligible.

@ahadas
Copy link
Member

ahadas commented Sep 16, 2023

@pskowronek that's a very partial review - I'm also in the process of trying to extract unrelated changes to make it easier to review

@ahadas ahadas force-pushed the faster_start branch 2 times, most recently from b46cb56 to 4bad0ff Compare September 16, 2023 10:18
build.gradle Outdated Show resolved Hide resolved
@pskowronek
Copy link
Member Author

PR updated with review comments (and rebased)

@pskowronek
Copy link
Member Author

@ahadas - another PR update, dirty fix for tests - let's think where to 'initialize' PreloadedJFrame (OsVersion wasn't meant to be the final place :) ).

@pskowronek pskowronek changed the title [PoC] muC Faster start up muC faster start up Apr 23, 2024
@pskowronek
Copy link
Member Author

@pskowronek looks great now, a minor comment inside please update the title and description of the PR, and document the change in the readme file

PR updated!

Copy link
Member

@ahadas ahadas left a comment

Choose a reason for hiding this comment

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

@pskowronek thanks!

@ahadas ahadas merged commit 4030191 into mucommander:master Apr 23, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

muCommander startup was faster with OSX 10.11 and muCommander 0.9.0
2 participants