Hi!
I am using telerik RadComboBox.I have records more then 40,000.I also binded data.Everything is working fine.but problem is it takes too much time.Even brower show "Kill Page" or "Wait" message.I'm also used its properties MarkFirstMatch="true" and Filter="Contains".I also tried EnableAutomaticLoadOnDemand and EnableLoadOnDemand of its properties but they only show "Loading.........." nothing else.One more thing i have to add, this combobox in RadScheduler AdvancedForm Control.
Thanks in advance.
I am using telerik RadComboBox.I have records more then 40,000.I also binded data.Everything is working fine.but problem is it takes too much time.Even brower show "Kill Page" or "Wait" message.I'm also used its properties MarkFirstMatch="true" and Filter="Contains".I also tried EnableAutomaticLoadOnDemand and EnableLoadOnDemand of its properties but they only show "Loading.........." nothing else.One more thing i have to add, this combobox in RadScheduler AdvancedForm Control.
Thanks in advance.
1 Answer, 1 is accepted
0
Shinu
Top achievements
Rank 2
Rank 2
answered on 28 Aug 2013, 07:27 AM
Hi Danish,
If you have more than 40,000 data items, such an issue is expected. In order to solve this issue to some extend, you could use virtual scrolling and not return the entire set of data. The main purpose of this approach is to let you load portions of the combobox items in each ItemsRequested event handler to achieve a faster loading speed. You can read this help article on virtual scrolling to get the general idea.
I would say that what you are seeing it's quite normal. In a scenario with such a huge set of data, say 45,000 items would have approximately the following footprint:
25 bytes just for the items,
5 bytes for the base text
Near about 3 to 5 bytes for the counter text.
As well as some JSON data.
Multiply by 45000 and you are close more than 1575000 bytes, that is more than 1.5 MegaBytes of postback content. Browsers, especially old browsers such as IE8 are notoriously slow with that much content. Apart from that, these huge set of contents need to be parsed to HTML elements and all JS things set. Even a postback content of 100 KB can cause a delay of about 10 seconds in browsers such as IE8. So you can imagine how it will be with 1.5 MB of data. But I found Chrome on the other side is a bit more fast and 100KB of postback content will not slow it down that much.
Thanks,
Shinu.
If you have more than 40,000 data items, such an issue is expected. In order to solve this issue to some extend, you could use virtual scrolling and not return the entire set of data. The main purpose of this approach is to let you load portions of the combobox items in each ItemsRequested event handler to achieve a faster loading speed. You can read this help article on virtual scrolling to get the general idea.
I would say that what you are seeing it's quite normal. In a scenario with such a huge set of data, say 45,000 items would have approximately the following footprint:
25 bytes just for the items,
5 bytes for the base text
Near about 3 to 5 bytes for the counter text.
As well as some JSON data.
Multiply by 45000 and you are close more than 1575000 bytes, that is more than 1.5 MegaBytes of postback content. Browsers, especially old browsers such as IE8 are notoriously slow with that much content. Apart from that, these huge set of contents need to be parsed to HTML elements and all JS things set. Even a postback content of 100 KB can cause a delay of about 10 seconds in browsers such as IE8. So you can imagine how it will be with 1.5 MB of data. But I found Chrome on the other side is a bit more fast and 100KB of postback content will not slow it down that much.
Thanks,
Shinu.