Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Upgrade react-range to fix memory usage of sliders (streamlit#6764)
As mentioned in https://blog.streamlit.io/six-tips-for-improving-your-streamlit-app-performance/ memory usage struggles in the browser if you have large ranges: > Due to implementation details, high-cardinality sliders don't suffer > from the serialization and network transfer delays mentioned earlier, > but they will still lead to a poor user experience (who needs to > specify house prices up to the dollar?) and high memory usage. In my > testing, the example above increased RAM usage by gigabytes until the > web browser eventually gave up (though this is something that should > be solvable on our end. We'll look into it!) This was caused by a bug in react-range, which I fixed last year. tajo/react-range#178 At the time, I had figured it would get picked up by a random yarn upgrade and didn't worry too much about it. But, apparently yarn doesn't really have an easy way of doing upgrades of transitive dependencies (see yarnpkg/yarn#4986)? I took the suggestion of someone in that thread to delete the entry and let yarn regenerate it. Some technical details about the react-range fix from the original commit message (the "application" is a streamlit app): > We have an application that uses react-range under the hood, and we > noticed that a range input was taking 2GB of RAM on our machines. I > did some investigation and found that regardless of whether the marks > functionality was being used, refs were being created for each > possible value of the range. > We have some fairly huge ranges (we're using the input to scrub a > video with potential microsecond accuracy), and can imagine that > other people are affected by the previous behavior. This change > should allow us to continue using large input ranges without > incurring a memory penalty.
- Loading branch information