Tools menu is ridiculously slow on MacOS

[MCUdude]

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

[facchinm]

It looks like #7924 is back 😢
Could be a duplicate of #9260 but the "Updates available" trigger could help debugging the issue properly.

[MCUdude]

I'm not getting any significant lag if I don't enter the tools menu.

[AIlgorithm]

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.

[delcomp]

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.

[facchinm]

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)

[delcomp]

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.

[PaulStoffregen]

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.

[PaulStoffregen]

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.

[delcomp]

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.

[delcomp]

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.

[MCUdude]

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!

[facchinm]

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

[delcomp]

Yes I can test that. Just tell me when the hourly build is available and were I can download it.

[facchinm]

It should be ready now (even if the tag still says "last update 11 Oct") , let me know the results! Thank you so much

[delcomp]

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.

[AIlgorithm]

@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.

[facchinm]

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... 😞

[delcomp]

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.

[AIlgorithm]

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 !!

[AIlgorithm]

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.

[facchinm]

@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

[AIlgorithm]

@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

[mdxtinkernick]

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

[mdxtinkernick]

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.

[paullbart]

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.

[45gfg9]

Somehow I didn't succeed reproducing this. How strange

[IAmOrion]

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)

[PaulStoffregen]

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?

[mdxtinkernick]

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

[mdxtinkernick]

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

[IAmOrion]

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?

So I tested the Teensyduino for a few days - it's definitely better, it happens less often for me, but it is still happening.

For what ever reason, and even though it's really a bad solution, swapping the java file did fix my official release version

[mdxtinkernick]

Adding all the boards did not reproduce the issue - so I went back to the original login and removed all traces of additional installed boards and the behaviour persisted, so I removed all installed software libraries - and that appears to have fixed it. I had a large number of libraries installed so have not tried adding them, will re install them as I need them and if I find a point where the behaviour returns will let you know

[makegeneve]

Interesting. I went through and removed the ten or so old libraries that were under the INCOMPATIBLE menu in Examples. That seems to have dramatically improved things. I still have dozens of libraries installed, including all the Teensy ones.

[IAmOrion]

Interesting. I went through and removed the ten or so old libraries that were under the INCOMPATIBLE menu in Examples. That seems to have dramatically improved things. I still have dozens of libraries installed, including all the Teensy ones.

Bear in mind, (for whatever it's worth) that libraries showing as "INCOMPATIBLE" is dependant upon which board is selected at the time. Some libraries will show as INCOMPATIBLE for example, if ESP32 is selected, because they're AVR only... if you change the board back to Arduino Uno for example, those that you saw as INCOMPATIBLE will now be valid and no longer "INCOMPATIBLE"

[makegeneve]

Hmm, then I must have been lucky with one. Thanks for the heads-up. The spinning beachball appears on Tools sometimes, but only for 1-2 seconds now, rather than the twenty or so it was before.

[cmaglie]

@makegeneve any chance to know the name of the library so we can try to reproduce?

[makegeneve]

I'll try to add them back one at a time, to see if it's just one.

BUT, a thought occurs, File and Tools menus are the ones that change when you change board - they seem to be doing the work to change only when selected, causing a delay - perhaps they should be changed when the board is changed?

[makegeneve]

Another thing I just tried - changed board to Arduino Uno - Tools menu appears in 3s. Changed board to LOLIN D1 R2 & Mini - Tools menu appears in 8s the first time - 3s afterwards.

[makegeneve]

OK, now I find that really strange, and understand why this bug is so hard to track down.

I moved the libraries back, one at a time, until they were all back, and the delay is still gone.

[makegeneve]

To be clear, I was moving the library folders out of the Libraries folder, and moving them back into it. Each move while Arduino.app wasn't running. I wasn't even re-installing from the Library Manager :-(

[rei-vilo]

Same here, almost 1 minute to get the Tools menu appear with Arduino IDE 1.8.11 running on macOS 10.15.3.

[PaulStoffregen]

@rei-vilo - Maybe try the old JRE hack? For instructions, scroll up to my message on Oct 21, 2019.

Would be interesting to know if it still works with Arduino 1.8.11 and MacOS 10.15.3. Apple keep gradually tightening security around code signing and soon (Feb 3, 2020) notarization.

[rei-vilo]

@PaulStoffregen Thank you for the pointer.

I went through the posts but, alas, I'm using macOS Catalina.

Moreover, Arduino 1.8.11 has now a folder Arduino.app/Contents/PlugIns/jdk1.8.0_99.jdk and no longer a plug-in Arduino.app/Contents/PlugIns/JavaAppletPlugin.plugin like in 1.8.5.

[Edit] Replacing the content of Arduino.app/Contents/PlugIns/jdk1.8.0_99.jdk/Contents by the content of Arduino.app/Contents/PlugIns/JavaAppletPlugin.plugin/Contents raises an error message at launch:

[PaulStoffregen]

You probably need to rename "JavaAppletPlugin.plugin" to "jdk1.8.0_99.jdk", since the pathname jdk1.8.0_99.jdk is written into the main Info.plist file. 1.8.11 won't look for the JRE in a folder with any other name.

[rei-vilo]

Yes, the modified Arduino IDE contains Arduino.app/Contents/PlugIns/jdk1.8.0_99.jdk/Contents. I've edited the previous message accordingly.

[amordicus]

All menus are awfully slow on Mac os Catalina and High Sierra. I'm using Arduino IDE 1.8.13. Sometime the menu selection can take more than a minute (spining beach ball) or hangs entirely and I have to do a "force quit".

I'm looking forward to the next version of Arduino Pro!

[45gfg9]

Well I am experiencing this too (#7924 again)

When exploring examples and changing boards I experience noticeably lag.
Is that I have installed about 10 different boards and more libraries?
Well, I'm currently turning to PlatformIO. Looking forward to Arduino Pro, too.

Edit. Lag happens on both Catalina and Big Sur

[PaulStoffregen]

Is that I have installed about 10 different boards and more libraries?

Could be a factor. But please consider how any attempt to answer this question is literally bling guessing, since nobody can see your screen over the Internet. We can't know which 10 boards you've using, which ports the IDE is discovering, or what libraries you have installed.

Maybe consider taking a couple screenshot with Shift-Cmd-3, showing the contents of the Boards and Ports sub-menus, and maybe also File-Example menu.

[PaulStoffregen]

Also, as your first troubleshooting step, turn off bluetooth! Certain BT devices have been known to cause 30 second stalls.

[delcomp]

I have this same problem for more than a year now. I use Arduino on multiple Macs and totally different hardware setups, but on each and every setup I have this problem. I do use the same cloud sync Arduino15 folder on all configs. This problem is not hw related. I'm now stuck on 1.8.10 which I've patched with an older java library. 1.8.13 I can't do the same trick, so anything after 1.8.10 I can't use. This is a real PITA problem. I just can't believe it has not been solved after more than a year. @PaulStoffregen I disable BT on my Mac (which is also a pain, as the keyboard & mouse are BT), but that didn't change a thing, same problem. Once 1.8.10 does not run properly anymore on new macOS versions, I'm afraid I will have to find an alternative for the Arduino IDE, because this problem makes the tool impossible to use during development.

[PaulStoffregen]

Yes, I know it's painful & frustrating.

Please understand not everybody has seen this problem. Arduino 1.8.13 definitely does not do this on my Macbook Air. I'm guessing the Arduino developers (I do not work for Arduino - I just occasionally contribute) probably aren't experiencing this problem either.

If you and others who do have this problem are unwilling to share screenshots and specific info, how will Arduino or anyone like me who might try to fix the problem even begin to work on it, when it doesn't happen on our Macs?

Screenshots are super easy on MacOS. Just press Shift-Cmd-3 and your Mac saves a screenshot to the desktop. Open it in any image editor to crop away any private info. You can then just drag and drop the image right from your Mac's desktop into your message on this github issue. Please, I beg of you, put your energy into showing us how to reproduce this painful problem. Yes, I know it suck and makes you want to never use Arduino again. But before you do that, spend just a moment to show the details rather than spending every word to express your pain & suffering, so maybe someday it might actually get fixed and others won't have to also endure this terrible lag.

[delcomp]

I’m perfectly willing to help you or the Arduino team solve this problem. Just tell me how I can help you. I know how to make screenshots, but what screenshot do you want? Opening files is slow, difficult to catch on a screenshot.

But again, tell me what to do and I’ll test it on my machines.

[PaulStoffregen]

At the very least, 3 screenshots showing the Tools > Boards menu, the Tools > Ports menu, and File > Example menu can let us know which boards you've installed, what libraries you've installed, and when hardware the IDE is detecting.

Please close Parallels & any other virtual machine software. Also try turning off all wired and wireless networking. Try a test with a little connected to your Mac as possible. You might discover one of those things is related.

But even if you don't find anything, the idea is to give me & others an idea of how to reproduce the problem. I can assure you absolutely is not happening on my Macbook Air right now. If I try loading the same things on my Mac that I see in your screenshots and the problem still doesn't happen on my machine, you can be 100% sure I won't be able to do anything to help. The idea is to rule out as much as possible, to maximize the chance of developers managing to reproduce the issue.

[delcomp]

Ok, here we go.

Mac mini, simple hw setup: one USB3 connected to an external drive. One USB-C connected to my monitor. A hub connected to the monitor for keyboard and printer.

For your test: I removed everything (one-by-one), but the problem still occurs. So, unplugged external hard drive, removed all devices form the hub except the keyboard, disabled WiFi & Ethernet, Quit Parallels.
The only thing I've noticed that's by disconnecting the connection to the Internet the wait is getting much longer.

The screenshots:

I do not have access now to my second system. But that is an iMac with nothing external connected except for a USB keyboard. There is a BT mouse and only a WiFi internet connector, no wired network. The problem is the same. As I've already mentioned, I use the same Arduino15 folder on both machines, synced via iCloud. This allows me to work on exactly the same setup on both machines.

Need anything more, just ask.

[45gfg9]

Well, I recorded my screen FYI:

comp.mov.gz

Bluetooth connected only to keyboard and trackpad, two external HDD and a mouse receiver attached.

My external board URLs if you want:

https://arduino.esp8266.com/stable/package_esp8266com_index.json
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
http://digistump.com/package_digistump_index.json
https://raw.githubusercontent.com/stm32duino/BoardManagerFiles/master/STM32/package_stm_index.json
https://raw.githubusercontent.com/tenbaht/sduino/master/package_sduino_stm8_index.json
https://mcudude.github.io/MicroCore/package_MCUdude_MicroCore_index.json
https://raw.githubusercontent.com/MHEtLive/arduino-boards-index/master/package_mhetlive_index.json

[delcomp]

I copied the old (1.8.5) JRE folder in the 1.8.13 Contents/Plugins folder and renamed it jre8u252-b09.jre. And voila, 1.8.13 works without delays with the old JRE. Don't understand why, but this old dirty trick still seems to work.

[dfleck]

I am SOOOO glad I found this thread. This has been so very frustrating. Files are still slow to open (over 1/2 minute), but the Tools and Example menus are now much faster with this workaround. I'm running 1.8.16 on OS 10.14.6 on a MacBook Air.