Multi Select "Select all" performance bottleneck on large datasets

[LazerLars]

Checklist

• I have searched the existing issues for similar feature requests.
• I added a descriptive title and summary to this issue.

Summary

When using st.multiselect it now includes "Select all" (was introduced in Streamlit version 1.55.0 (via Pull Request #13015) it casues the browser to freeze when clicking select all when having + 100 k items loaded into it, was not a problem before this was added.
I want the options to disable the "select all" button as argument to make the mulitselect component behave like previous versions

Why?

it makes the browser freeze

How?

st.multiselect(label="large multi select", options=largeListOf165k, disableSelectAll=True)

Additional Context

 import time
    import streamlit as st
    st.title("Performance Defect: Cascading st.multiselect with Large Datasets")

    st.markdown("""
    ### Feature Request Context
    This example demonstrates a performance bottleneck involving two dependent `st.multiselect` widgets. 

    Selecting a category in the first widget filters the available choices in the second widget. When the underlying dataset contains 165,000 items, clicking the native **Select all** button on either widget triggers severe serialization overhead, memory spikes, and completely freezes the browser interface on a thinkpad p16 gen 1.

    **Requested Feature:** A configuration parameter to natively disable the "Select all" option (e.g., `show_select_all=False`).
    """)

    # Mock data: 3 groups, each containing 55,000 items (165k total rows)
    GROUPS = ["Group_A", "Group_B", "Group_C"]
    ITEMS_PER_GROUP = 55000

    # First widget: Select groups
    selected_groups = st.multiselect(
        label="1. Select Item Groups", options=GROUPS, default=["Group_A"]
    )

    # Generate dependent options based on the selection in the first widget
    available_options = []
    for group in selected_groups:
        available_options.extend([f"{group}_Item_{i}" for i in range(ITEMS_PER_GROUP)])

    # Second widget: Filtered choices based on the first widget
    # Clicking 'Select all' here on a large subset causes immediate UI failure
    selected_items = st.multiselect(
        label=f"2. Filtered Items (Current available choices: {len(available_options)})",
        options=available_options,
    )

    st.write(f"Total items selected in widget 2: {len(selected_items)}")

[github-actions]

To help Streamlit prioritize this feature, react with a 👍 (thumbs up emoji) to the initial post.

Your vote helps us identify which enhancements matter most to our users.

[github-actions]

This is a feature request (with a performance angle) for st.multiselect. The user reports that the "Select all" option added in Streamlit 1.55.0 (via PR #13015) causes the browser to freeze when the widget contains very large option lists (e.g., ~165k items). They are asking for a parameter (e.g., show_select_all=False / disableSelectAll=True) to opt out of the built-in "Select all" UI so the widget behaves like it did before 1.55.0.

Looking at the implementation in frontend/lib/src/components/widgets/Multiselect/Multiselect.tsx, clicking "Select all" replaces the entire value array with all currently unselected options ([...value, ...unselectedValues]), which then has to be: (1) re-rendered as tags by baseweb, (2) serialized into a protobuf StringArray, (3) sent to the backend over the WebSocket, and (4) returned to the script as a list. With 165k items this is a very large state payload, so the bottleneck is inherent to the "select everything at once" interaction rather than to a specific bug — making the requested opt-out a reasonable enhancement. Note that st.multiselect is generally not designed for this scale of options; a server-side filter (or an autocomplete-style API) is usually the more scalable pattern.

Related Issues

• #14918 — Option to enable/disable the select all option on st.multiselect: Essentially the same feature request (parameter to disable the built-in "Select all"), but motivated by UX (a chart with 1000+ traces) rather than performance. This issue should likely be consolidated with Option to enable/disable the select all option on st.multiselect #14918.
• #4714 — Add select all shortcut or button for multiselect (closed): The original request that led to the "Select all" feature in 1.55.0 (PR Select all or select all matches in st.multiselect (plus drop down styling) #13015). Useful context for the history of the feature.
• #12644 — Make st.multiselect not wrap the selected options / keep its height: Related secondary UX problem when many options are selected — after a "Select all" the widget can grow enormously in height because every selection is rendered as a tag chip.

---

This is an automated triage comment using claude-opus-4-7-thinking-xhigh. Please verify the suggested labels and related issues.