I can't answer the speed comparison you ask for since the things listed are completely different things.
Let me explain that briefly:
IEnumerable is just an interface that provides you with a bunch of extension methods and iterator functionality. Notable collection classes that implement IEnumerable would be e.g. a Dictionary<>, or an ObservableCollection<> or a List<> for that matter.
ReadOnlyCollection (and I assume you don't mean IReadOnlyCollection) is a concrete implementation of IReadOnlyCollection that wraps around an existing class that implements the IList interface. You pass that into the constructor and it will give you read only access to the content of the collection.
ObservableCollection implements among other things IEnumerable and IList interfaces.
Assuming from the context of your question you ask if there are specific collections that you can bind to ComboBoxes or ListBoxes and alike that are preferable in terms of speed.
Let's look at the WPF ComboBox:
Its ItemsSource property asks for an IEnumerable, and as stated above you can use any concrete class that implements that interface. You mentioned ObservableCollection, that one is interesting because it implements the INotifyCollectionChanged interface.
It allows you to do the following: Once you have an ObservableCollection bound to the ItemsSource of the ComboBox if you e.g. Add() or Remove() items from it the ComboBox will get notified of the change and reflect that by adding, or removing items from the list of visible things in the dropdown. If you used e.g. a List<> instead that would not happen and you would have to rebind/reassign the ItemsSource again.
Let's get back to the speed question, we can break that down into several parts:
- Construction of your collection:
A List will be cheaper to construct than an
ObservableCollection
simply because of the fact that Observable collection has to
repeatedly raise the CollectionChanged event. So if you know that
you collection never changes and you can construct it completely
before you assign it to the ItemsSource you can use a List
instead.
- Maintainance of the collection: As mentioned in 1. if the collection never changes and can be pre-constructed, don't use an
ObservableCollection, use the List
instead
- (Probably most interesting for you) Rendering of items: Depending on the Container (e.g.
ListBox or ComboBox or any other for that matter) the largest amount of time will be spent
rendering the items unless the control virtualizes the items.
--What does #3 that mean?
Imagine you have a collection of 300 items and assign that to your container:
If it is not virtualized it will start rendering all 300 items which takes a while but you will likely only see a subset of them on the screen all the other ones are hidden and you have to move a scrollbar to get them into view.
If the control can virtualize it will render only the part you can see right now and maybe a couple extra directly adjacent and then when you scroll start rendering the ones that come into view on demand. This is significantly faster initially and maybe a little bit slower during scrolling.
Points 1 and 2 are likely very negligible for such small lists with 300 items, however you will likely want to look into #3. Even already for smaller datasets virtualization makes a huge difference because most of the time is spent rendering especially if you have complex/slow Styles or DataTemplates
This might not directly answer your question but will instead give you a hint into which direction to focus your efforts.
