I am running into a strange performance problem when running my Streamlit app locally (it is not yet deployed to a cloud). I believe the root of the problem is due to some difference in how streamlit operates when running on an Intel processor versus the newer ARM64 Apple silicon chip.
On my old 2018 Macbook Pro (with an Intel processor), I can run my streamlit application locally, and it works seamlessly, handling the reading and processing across 50+ csv files with several user-inputs along the way. Everything also works fine if I run my application on a Linux server. Yay! Below are the specs for these 2 working machines:
2018 Macbook specs: 2.6GHz 6-core 8th-generation Intel Core i7 processor, Turbo Boost up to 4.3GHz
Linux specs: Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-173-generic x86_64)
However, I recently got a new Macbook Pro with an M4 Pro chip, and now the same exact workflow with the same exact files causes my application to stall out and my Performance cores to all max out at nearly 100%. I’m noticing this problem happens at a specific point in my workflow:
- User uploads desired csv files (usually in the 30-100 range)
- IF the files are not uploaded: then a sentence appears telling the user to upload their files.
- ELSE (if the user has correctly uploaded their files): then the user is prompted to define several variables using number_input, selectbox, and multiselect functionality
- Everything works fine EXCEPT for the multiselect box. If I choose more than ~4 values here, the application stalls, the running icon appears in the upper right corner, and all of the Performance cores on my new laptop max out.
- The code then goes on to check that all of the user inputs are answered and then runs the rest of the application. However, it never seems to get to this point if too many values are chosen in the multiselect box.
I’ve discovered a workaround, which also points to my theory that streamlit is not playing nicely with the arm64 architecture here. The workaround involves using Rosetta in my Terminal application. When I force my new M4 Pro Mac’s Terminal to “Open using Rosetta” and then I follow the same exact workflow that originally triggered the problem on this machine, everything works fine. This workaround is fine for the time being, but I wonder if others are experiencing this issue and worry that something is up… Unfortunately the code is private and I cannot share it here, but I can provide more details if needed to try to replicate/debug.
Version info:
streamlit = 1.32.2 (I’ve confirmed the issue persists when trying with v1.42.2)
python = 3.10.0
MacOS 15.3.1
Here are screenshots of my Activity Monitor and the CPUs:
You can tell when I selected the 4+ values in the multiselect box, as it’s exactly when the 4 Efficiency cores decline and the 10 Performance cores spike (also see the change in the CPU Load graph in the bottom of the left window and note the %CPU is over 600%):
After waiting several seconds, it’s still swirling:
And many minutes later, it still has not loaded:
The time it takes to accept the multiselect values and move on in the code appears to be directly related to the number of values selected. Selecting 4 values may take 10ish minutes to load, but selecting 10+ values suddenly takes over an hour to load. On my Intel mac, Linux server, and using Rosetta on the M4 Pro mac, this takes no more than a few seconds max (often less than 1 second).
I’ve also tried running a simple multiselect functionality test app without the big if/else code block that follows, and it works fine on my new laptop. This indicates to me that streamlit is trying to run the (whole?) app as many times as there are values selected or something weird like this??
Can someone please help look into this? Thank you!