-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Version 1.8.2 three times slower to launch #6350
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
Comments
Maybe the newer JRE? |
I have the same issue, for me the launch time for 1.8.2 and 1.8.3 is 27 seconds |
Some of the problem (maybe most of it) is due to something in the IDE that ends up scanning the users sketchbook libraries and cores multiple times. It does this on startup or any time you switch cores. This has existed for many years but seems to have gotten worse recently. In the past it was very obvious for me as certain IDEs had some foolish naming restrictions on library directory names and I would have to answer the same prompt for a given library directory name up to 9 times for each directory it didn't like on startup or whenever I switched cores. |
@bperrybap I agree with you, I can see Arduino scanning libraries during startup with: |
Thank you for confirming that I'm not the only one who has found this. I definitely think it would be worth the developers spending a bit of time to fix this. |
The multiple scanning of the libraries can be surely optimized, but it has been like this well before 1.8.1, IMHO the cause of the slow down should be searched elsewhere. |
I have found that "phony" serial ports (e.g. Bluetooth virtual such) can be startup time culprit. Can this be an issue here? |
Thanks for pointing that out @bengtmartensson |
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate arduino#6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate arduino#6350
I've tried the test build from #6419 but it still takes 35 seconds to launch |
Issue still present in 1.8.4 |
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Fixes arduino#6350 (the regression was introduced with b2241da ) Thanks git-bisect :)
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Want to confirm that this is still present in 1.8.5. =) |
@jaygarcia could you test 1.9.0 beta? It should contain an additional fix (5c61508) that should solve the issue. Thansk! |
1.9.0 beta solves the issue for me |
I confirm that 1.9.0 beta launches in 4 seconds, matching the behaviour of 1.6.8 and 1.8.1. That's great news - a big thank you to everyone who worked to achieve this! |
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
@jaygarcia dunno if this still matters, but I see this problem in 1.8.5. |
@SuperTango this seems to be fixed in 1.9 beta: https://www.arduino.cc/en/Main/Software#beta This ticket can most likely be closed once 1.9 is released to prod. Fantastic work everyone and thank you so much for fixing this! <3 |
/cc @facchinm |
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Fixes arduino#6350 (the regression was introduced with b2241da ) Thanks git-bisect :)
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate arduino#6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
Scanning libraries is an heavy task if the sketchbook becomes huge; This patch targets two points: - remove the rescan() after setLibrariesFolders(), which already performs a rescan - call setLibrariesFolders() only when the folder list has changed - This ensures that no scan is performed when changing board in the same architecture Could mitigate #6350
I've been comparing the time to launch 1.6.8, 1.8.1, and 1.8.2 on a MacBook Pro (Mac OS X 10.11.6).
Both 1.6.8 and 1.8.1 take 4 seconds, but 1.8.2 takes 13 seconds, over three times slower.
Any suggestions why this might be?
The text was updated successfully, but these errors were encountered: