-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
muC faster start up #1044
Conversation
...mander-protocol-adb/src/main/java/com/mucommander/commons/file/protocol/adb/AndroidMenu.java
Outdated
Show resolved
Hide resolved
junit drags it:
|
1582683
to
ce2a4da
Compare
any hint where to add exclusion? |
PR updated to address: #492 (comment) |
PR updated - faster UI start up. |
544506a
to
d157fe2
Compare
@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? |
0963f98
to
8c7132f
Compare
@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 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 |
5ec410e
to
2dd2c2c
Compare
2dd2c2c
to
3b9da66
Compare
var jarPath = jarFile.toURI().toString(); | ||
if (jarPath.contains("dropbox") || jarPath.contains("jediterm") | ||
|| jarPath.contains("protocol-gcs") || jarPath.contains("viewer-pdf") | ||
|| jarPath.contains("gdrive")) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
mucommander-bonjour/src/main/java/com/mucommander/bonjour/BonjourDirectory.java
Outdated
Show resolved
Hide resolved
mucommander-core/src/main/java/com/mucommander/ui/main/SplashScreen.java
Outdated
Show resolved
Hide resolved
@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 |
b46cb56
to
4bad0ff
Compare
mucommander-core/src/main/java/com/mucommander/Application.java
Outdated
Show resolved
Hide resolved
4bad0ff
to
954cb0d
Compare
mucommander-core/src/main/java/com/mucommander/ui/main/SplashScreen.java
Show resolved
Hide resolved
mucommander-core-preload/src/main/java/com/mucommander/preload/PreloadedJFrame.java
Show resolved
Hide resolved
954cb0d
to
ba7990c
Compare
mucommander-translator/src/main/resources/dictionary.properties
Outdated
Show resolved
Hide resolved
ba7990c
to
fc3a630
Compare
PR updated with review comments (and rebased) |
@ahadas - another PR update, dirty fix for tests - let's think where to 'initialize' PreloadedJFrame (OsVersion wasn't meant to be the final place :) ). |
039c5cc
to
ad887f8
Compare
… background - fix for ISE
… background - fix for ISE2
…ad deferred, no clipboard check on start
027fc62
to
88cd240
Compare
PR updated! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pskowronek thanks!
-XX:+TieredCompilation -XX:TieredStopAtLevel=1
- these gave quite a lot of boost (https://stackoverflow.com/a/46516509/1715521)Those changes make loading times 2-3 faster (3s->1s on Andreas' mac, on my mac from 6-7s->~2.6-3s).
Remarks: