Arduino
Arduino copied to clipboard
arduino
Tools menu is ridiculously slow on MacOS
This issue has become worse and worse with the recent IDE releases. When I first open Arduino IDE and click on the Tools menu, it appears on the screen immediately. However, as soon as the message "Updates available for some of your boards and libraries" it becomes incredibly slow, and it can take up to 20 seconds from I click the Tools menu before it appears. While I'm waiting, the cursor is just a spinning ball.
Is this somehow caused by the boards manager? FYI I'm running Arduino 1.8.10 and MacOS 10.14.5
It looks like https://github.com/arduino/Arduino/issues/7924 is back :cry: Could be a duplicate of https://github.com/arduino/Arduino/issues/9260 but the "Updates available" trigger could help debugging the issue properly.
Can confirm the issue (running on my MacOS 10.11.6 and Arduino 1.8.10 ). If you try to select the Tools menu after the long delay the first time, it display quickly. Any upload or compile will trigger the delayed display again.
Also confirm this issue. It appeared around 1.8.5 and has never been away since. Old 1.9.0 beta releases did solve it, but current 1.9.0 beta has the same problem. I use a Mac, Catalina (but this problem migrated from 10.14). It's now getting very annoying. Why is this long standing issue still not solved.
It's still not solved because we haven't been able to reproduce yet. A useful debug could be running the ide inside a java profile and report which function blocks. In case of #7924 it was due to a bug in java, it may be the same (but to be sure we need to reproduce it first or get some proper debug log)
Strange, I'm having this problem now for more then one year. Anyhow, I'm not a Java specialist, but if you tell me what to do, I can maybe make the log and send it to you. Glad to help you if it can help to remove this annoying bug.
The #7935 fix was only partially effective. The first time clicking the menu after changing boards is very slow when many extra libraries are added. This impacts Teensy, since we include about 80 libraries with the platform package. I understand it's a problem deep within Java that probably can't be fixed without Oracle's help.
If you're feeling adventurous and you have a pre-Catalina Mac, you could try hacking a newer copy of the IDE with the older Java runtime. To do this, you'd control-click each copy of Arduino and "show package contents". Then in each IDE, look in the Contents/MacOS and Contents/PlugIns folders. The JRE from Oracle is in Contents/PlugIns and the startup program is in Contents/MacOS. You might need to copy both, or maybe just copying Contents/PlugIns from an older copy (where the menus were fast) is enough? But this runs afoul of Gatekeeper. Before Catalina, it would not complain if you had already run the IDE once (to get past the downloaded from the internet warning) and you keep the files in the same place. Catalina tightens Gatekeeper security, which is probably a good thing in the long term for the Macintosh ecosystem, even though it closes the door to this sort of experimentation.
And which Java version is considered to be ok, i.e. without the delays? I could try removing the Arduino IDE, then re-install it, replace the Java runtime, finally to a first start. Maybe that solves the Gatekeeper issue.
PaulSotffregen, thanks for the tip. I replaced JavaAppletPlugin.plugin with the version of Arduino 1.8.5. And problem solved. Thanks a million times, this saves a lot of time and frustration.
I tried several versions, up until 1.8.5 it works perfectly. The JavaAppletPlugin.plugin included with Arduino 1.8.6 and higher have the annoying delay problem.
And no issues with Gatekeeper, I could just replace the file.
I replaced JavaAppletPlugin.plugin with the version of Arduino 1.8.5.
I also tried this, but with the one from 1.8.4. Problem solved for me too!
Unfortunately we can't revert the bundled jre version for a million reasons (like security issues and missing certificates from the embedded keychain). I'm currently producing some hourly builds using AdoptOpenJDK jres (https://adoptopenjdk.net/archive.html), they should be available in a few minutes. If you could test them and report if you see any outstanding bug it would be great
Yes I can test that. Just tell me when the hourly build is available and were I can download it.
It should be ready now (even if the tag still says "last update 11 Oct") , let me know the results! Thank you so much
Sorry, but this hourly build has the same problem. Each time you try to open a new file (Examples for example) you get the hourglass and have to wait for a minute or so. Also if you switch between two windows. For example when cut/paste between two windows. You get it I think, it's annoying.
@facchinm Thanks for the update and suggestion.
Here are my observation as i tested 3 version of Arduino: -1.8.5 -1.8.10 -1.8.11 Hourly Build 2019/10/22 10:16
I did not update the JRE bundled with the downloads and tested the Tools menu.
On 1.8.10 and on 1.8.11: 1 - If your board selected is an (Arduino AVR Boards, SAMD, megaAVR, Adafruit) when you open the app -Selecting a default Arduino Board like Arduino Nano cause no delay in the menu selection -Selecting another default Arduino board like UNO, or Adafruit Trinket cause no delay -Selecting an (ATTinyCore, megaTinyCore, MiniCore, MegaCoreX) will cause a delay 2 - If you Switch to another running application or minimize Arduino app or switch to the desktop, this will cause a significant delay when you re-select Arduino app and try to choose the Tools menu, regardless if your current selected board is an Standard Arduino AVR, or additional boards like ATTinyCore ...
On 1.8.5: 1 - None of the delays scenario described above apply on this version, with a small almost unnoticeable delay when Switching boards between default Arduino AVR .. and the ATTinyCore, megaTinyCore, MiniCore, MegaCoreX, or between ATTinyCore and MiniCore for example. 2 - No Delay when Switching to another application and returning to Arduino app.
Will do more testing later today on updating the JRE with different variation.
I'm still a bit shocked by the fact that I can't reproduce it in any osx installation I ever tried, so there must be something interfering and involving java, the osx installation, maybe file paths? It doesn't look easy to solve though... :disappointed:
Strange. I had this on my old iMac too. When I go my Mac mini (Dec 2018) I did a clean install of MacOS 10.14. I just imported my data via iCloud. Installed all apps from scratch. And I had this Arduino problem from day one. So it's not related to an old cluttered file system.
I always thought the Arduino app sometimes does a search through all the drive and also through slow links, for example OneDrive, DropBox, other slow internet based drives. Maybe that's the reason for the delay.
additional observation, after installing java JDK 13.0.1 even Arduino 1.8.5 have the delay problem now (did not have that before). Removing JDK solved the issue for 1.8.5.
Now sure what additional environment JDK added to OSX that caused the issue for 1.8.5 !!
Solved from my side Not is the way i expect but it's an indication where to look.
Removed the boards related to megaTinyCore and ATTinyCore from the Board Manager ( installed from http://drazzy.com/package_drazzy.com_index.json). This worked on all installed versions 1.8.5, 1.8.10 and 1.8.11 ( no delay issue when selecting the Tools menu ).
thought this help in solving the issue but i use the boards megaTinyCore and ATTinyCore and hope this can be tested to confirm before checking what the Board are adding to the app that cause the delay.
@AIlgorithm it could be a hint indeed to search if, to add additional entries, we are using some function that became superslow in recent java versions
@facchinm Did not check Arduino code but form the application performance i can see that the Tool menu is re-loaded every time we: 1- Click on the Tools Menu 2- Every time the Arduino application is in the background and get selected (explain why you get the delay if you minimize or switch to another application then back to Arduino - Arduino 1.8.11)
Not sure if their is a need to reload the Tool menu every time we have to click it, it should be refreshed only when you change any of the parameters - Hence no delay issue in 1.8.10 when clicking on the File/Edit/Sketch/Help , only the Tool Menu) Could be a buffer issue with the Java function and this is changed with newer Java plugin, as i understand version 1.8.11 is using AdoptOpenJDK and this cause all the menu to have a delay - and assuming you did not change the function for selecting the menu in the application. This need detailed Java debugging
I have been having issues with this to.
After reading this I noticed that on restart the tools menu and changing board definitions was working as normal (I rarely start, usually sleep the machine) Going to boards manager works fine, then when closing that window the window does not immediately close (~4 secs delay) and the spinning beachball replaces the pointer. After that changing board takes a similar amount of time or longer and the Arduino interface is not responsive while this is happening, with spinning beachball. Switching to other applications works fine, but returning to Arduino beachball returns.
This is on high Sierra with Arduino 1.8.10
Switching the JavaAppletPlugin.plugin with the version from 1.8.5 appears to have resolved this for me. Thanks. Happy to break it again to provide any info that may help track it down.
Switching the JavaAppletPlugin.plugin with the version from 1.8.5 appears to have resolved this for me. Thanks. Happy to break it again to provide any info that may help track it down.
Also confirming that this solved the issue for me.
I did a clean install of 1.8.10 on Mac OS Catalina when it hit GM.... I too have been suffering this painfully annoying delay bug!! I kept forgetting to check here on github, so was kind of relieved I wasn't the only one suffering and it is, in fact, a bug of some sorts.
Interesting that someone mentioned the drazzy repo, as I DO too have that in mine as do use some ATTiny Stuff
Here's my board urls for reference:
https://adafruit.github.io/arduino-board-index/package_adafruit_index.json
https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json
http://drazzy.com/package_drazzy.com_index.json
http://arduino.esp8266.com/stable/package_esp8266com_index.json
https://mcudude.github.io/MiniCore/package_MCUdude_MiniCore_index.json
https://raw.githubusercontent.com/Lauszus/Sanguino/master/package_lauszus_sanguino_index.json
https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json
https://dl.espressif.com/dl/package_esp32_index.json
https://github.com/Optiboot/optiboot/releases/download/v8.0/package_optiboot_optiboot-additional_index.json
https://docs.heltec.cn/download/package_heltec_esp32_index.json
https://raw.githubusercontent.com/LukasSchulz/arduino-boards-index/master/package_digistump_index.json
http://dan.drown.org/stm32duino/package_STM32duino_index.json
I will test swapping the javaapplet plugin others have mentioned - I presume there's no loss of functionality so to speak? (Ignoring security issues etc)
I presume there's no loss of functionality so to speak?
Well, it is downgrading the Java Runtime to a significantly older version (probably 8u121), and then running compiled Java bytecodes that were produced by a newer JDK (8u191). Normally when you run Arduino, the bundled JRE is precisely the same version as the JDK used to build the code. So while reports so far say it seems to work, this is pretty far from an ideal situation.
While you're at it, could I also talk you into testing with this Teensyduino beta?
https://forum.pjrc.com/threads/58817-Teensyduino-1-49-Beta-4
This is a copy of Arduino 1.8.10 with the Oracle Java runtime 8u191 replaced by OpenJDK's runtime version 8u232, and that newer JRE is compiled with a newer Apple SDK. The newer SDK will become a requirement for Apple's notarization process on Feb 3 (unless Apple delays this deadline again). So the big question is whether this menu speed bug happens with this newer stuff?
trying the teensyduino version meant for Catalina (so the full Arduino with teensy pre-installed, rather than applying it to pre-existing Arduino on my machine ), produced the same slow response from menus - this is on high sierra, not Catalina. Replacing the JavaAppletPlugin.plugin in the Contents/Plugins with the older version got rid of that behaviour again
I have just tried a new user account on my machine, with a fresh download of Arduino and the menus behave fine, even after running a board update.
So that suggests an issue with one of the board descriptions linked to or installed. Will try adding them incrementally and see if there is a point where it stop working.
For info the urls added in the preferences are:
http://digistump.com/package_digistump_index.json
http://arduino.esp8266.com/stable/package_esp8266com_index.json
https://adafruit.github.io/arduino-board-index/package_adafruit_index.json
https://redbearlab.github.io/arduino/package_redbearlab_index.json
https://github.com/Ameba8195/Arduino/raw/master/release/package_realtek.com_ameba_index.json
http://static.dev.sifive.com/bsp/arduino/package_sifive_index.json
https://raw.githubusercontent.com/ROBOTIS-GIT/OpenCR/master/arduino/opencr_release/package_opencr_index.json
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
https://s3-us-west-2.amazonaws.com/digilent/Software/Digilent_Core/package_digilent_index.json
https://github.com/sonydevworld/spresense-arduino-compatible/releases/download/generic/package_spresense_index.json
https://raw.githubusercontent.com/AloriumTechnology/Arduino_Boards/master/package_aloriumtech_index.json
https://dl.espressif.com/dl/package_esp32_index.json
https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json
https://sandeepmistry.github.io/arduino-nRF5/package_nRF5_boards_index.json
will let you know If I find anything over the next week