An example is here: https://github.com/NameFILIP/baseui-performance-test

Thanks for opening this @NameFILIP!
can you help us understand what's your use-case for 1500 options?
Also, I've run a quick comparison with Material UI: https://codesandbox.io/s/jnm2kj28w3 - it takes ~3 seconds with it.
With that said, I am sure we can do better! Do you want to take this on and look into it?
I tried replacing an existing component that we use (which takes 200ms). 500ms is very noticeable, so I'll hold off the migration to the baseui element. I might or might not investigate why it happens.
Rendering 1500 elements in the DOM is probably just a bad idea in general, especially if only ~10 are visible in the viewport at a given time. And nobody is going to look through a list of 1500 items anyway, they'll just search instead.
We probably want a virtualized list (https://github.com/bvaughn/react-window) or we can do something more naive and just show 50 until the user starts scrolling down to the bottom, then show 50 more, etc.
Note - performance drastically increases when not running components through a CSS Processor (in this case, styled components)
Not saying you should extract all styling into inline styles, just something I've found.
Used a custom component dropdown with 1500 items and ran through react profiler
Inline styles - 79ms initial render

With styled components - 180ms initial render

Here's my quick method to speed up rendering, slice the options list to 20 items max, after doing text match filtering. Means they can't scroll through the whole list, but the faster rendering during typing is more important IMO.
<StatefulSelect
options={this.props.options
.filter(t => {
return this.state.value ?
t.label.toLowerCase().indexOf(this.state.value.toLowerCase()) === 0 : true;
}).slice(0, 20)}
placeholder="Select an option"
onInputChange={e => {
this.setState({value: e.target.value || ''});
}}
onChange={({value, option, type}) => {
if (type === 'clear') {
return this.setState({value: ''});
}
this.props.selectOption(option.id);
}} />
This is a good idea, especially for large datasets where no sane user will ever desire to scroll through all 1000+ points. Although it feels wasteful to define a custom filter when that functionality is built into select. I wonder if we could request a change in the API for that - to add a 'max rendered items' prop...
Added an example to show integration with react-virtualized. Maybe create a stack overflow post with the baseui tag to share other approaches to handle this use case?