Poor performance searching Dropdown with ~1k options


I am finding the Dash Core Components Dropdown is becoming unusable once the number of options increases past a few hundred. If each option label is a very small amount of text then it performs better, but if there is any significant text in the option labels, the performance goes downhill quickly. I’ve looked all over and cant seem to find any resolution or even people coming across the same issue. There are a few posts around complaining about initial load time, which is ok for me, but the filter/search time is the problem. The searching is incredibly slow with 1000 options, 30 characters in each label. Do other people have the same issue as me if running the code below? My end goal is to be able to search from a list of up to ~5000 options with 30-50 characters each.

This post mentions having 40K -100k options, with no performance issues searching the dropdown: Loading dropdown component with many items is slow · Issue #441 · plotly/dash-core-components · GitHub

The only resolution that seems to be relevant is the dynamic options, which still shows sluggish performance when implemented with the options below

Running dash V2.5.1, dash-core-components v2.0.0

Any help or ideas is greatly appreciated! Thanks!


from dash import Dash, html, dcc

import random
import string

options = []
for i in range(1000):
    options.append({"label": ''.join(random.choices(string.ascii_lowercase, k=30)), "value": i})

app = Dash(__name__)
app.layout = html.Div([
        # [{'label': 'dyno/custom devices/can trace manager/controls/can log trigger', 'value': 'test9'}],
        style={'padding': '2px', 'text-align': 'center'},  # 'width': '750px',
        placeholder='Source-Signal Name',

if __name__ == "__main__":

You can use dmc.MultiSelect, combining the “searchable” and the “limit” property. Works for my dropdown with more than 10’000 options.





Thanks a ton Yanboe!! Very much appreciated!

For anyone experiencing the same issue, it appears to have been fixed in dash 2.7.0

I think PR #2293 was responsible for the fix, I do not completely understand how the fix works but it looks like it was essentially re-indexing each time a value (individual characters) was added to the search box, rather than persisting the index.

1 Like