sorting freezes UI

[lexthang]

Sorry if this sounds like such a fundamental question .. I search the forum but didn't find anything similar (there's only one post about frozen UI for a few seconds when creating an EventList of a few hundred items list)

So we have a table of hundreds of thousand of rows .. We notice that when we click on some column to sort, the UI becomes unresponsive for minutes. It appears the cause is due to the sorting is being done in the main event thread itself. Is there away we can move the sorting to another thread safely? I understand something like that might need to be intricate, since the click-handling is totally inside glazedlist, which means some types of callback might be necessary. Still, it would be a really really great thing if we can have something like that .. or some pointers on what might be possible.

Thank you!

[James Lemieux]

Lex,

   I'm surprised to hear the UI is unresponsive for *minutes*... that seems excessive. Make sure you've written your Comparator(s) to be as fast as possible. Even things like reflection overhead is significant when you're dealing with 100,000+ elements. For 100,000 elements, I'd estimate 10 seconds is reasonable on most modern processors.... so "minutes" feels like something is wrong. Make sure you're not creating temporary objects in your Comparator, if you can get away from that...

   As for how to sort in the background.... you'll probably have to roll a custom solution for that. Our TableComparatorChooser makes assumptions, for example, that the "sorting model" and the SortedList are actually in sync, which is only guaranteed when they are both updated on the EDT. Even if you put the sorting on a background Thread, you'll have to keep the pipeline locked while the sort occurs, which will prevent other changes from taking place (subsequent sorts, adding new elements, etc), so there probably isn't much you can do here.

   To be clear, I think investigating the cause of the slow sort is your best course of action for the time being.

James

On Fri, Jul 18, 2008 at 11:20 PM, lexthang <lexthang@...> wrote:

Sorry if this sounds like such a fundamental question .. I search the forum
but didn't find anything similar (there's only one post about frozen UI for
a few seconds when creating an EventList of a few hundred items list)

So we have a table of hundreds of thousand of rows .. We notice that when we
click on some column to sort, the UI becomes unresponsive for minutes. It
appears the cause is due to the sorting is being done in the main event
thread itself. Is there away we can move the sorting to another thread
safely? I understand something like that might need to be intricate, since
the click-handling is totally inside glazedlist, which means some types of
callback might be necessary. Still, it would be a really really great thing
if we can have something like that .. or some pointers on what might be
possible.

Thank you!
--
View this message in context: http://www.nabble.com/sorting-freezes-UI-tp18541809p18541809.html
Sent from the GlazedLists - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Holger Brands]

Another reason for slow sorting could be enabled assertions:
http://www.publicobject.com/glazedlists/wiki/index.php?title=FAQ#Performance

Holger

>
> Lex,
>
>  I'm surprised to hear the UI is unresponsive for *minutes*... that
> seems excessive. Make sure you've written your Comparator(s) to be as
> fast as possible. Even things like reflection overhead is significant
> when you're dealing with 100,000+ elements. For 100,000 elements, I'd
> estimate 10 seconds is reasonable on most modern processors.... so "
> minutes" feels like something is wrong. Make sure you're not creating
> temporary objects in your Comparator, if you can get away from that...
>
>  As for how to sort in the background.... you'll probably have to
> roll a custom solution for that. Our TableComparatorChooser makes
> assumptions, for example, that the "sorting model" and the SortedList
> are actually in sync, which is only guaranteed when they are both
> updated on the EDT. Even if you put the sorting on a background
> Thread, you'll have to keep the pipeline locked while the sort occurs,
> which will prevent other changes from taking place (subsequent sorts,
> adding new elements, etc), so there probably isn't much you can do
> here.
>
>  To be clear, I think investigating the cause of the slow sort is
> your best course of action for the time being.
>
> James
>
>
> On Fri, Jul 18, 2008 at 11:20 PM, lexthang <lexthang@...> wrote:
>
>  Sorry if this sounds like such a fundamental question .. I search
> the forum
>  but didn't find anything similar (there's only one post about frozen
> UI for
>  a few seconds when creating an EventList of a few hundred items list)
>
>  So we have a table of hundreds of thousand of rows .. We notice that
> when we
>  click on some column to sort, the UI becomes unresponsive for
> minutes. It
>  appears the cause is due to the sorting is being done in the main
> event
>  thread itself. Is there away we can move the sorting to another
> thread
>  safely? I understand something like that might need to be intricate,
> since
>  the click-handling is totally inside glazedlist, which means some
> types of
>  callback might be necessary. Still, it would be a really really
> great thing
>  if we can have something like that .. or some pointers on what might
> be
>  possible.
>
>  Thank you!
> --
>  View this message in context: http://www.nabble.com/sorting-freezes-
> UI-tp18541809p18541809.html
>  Sent from the GlazedLists - Dev mailing list archive at Nabble.com.
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>
>
>

_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...