CODEWITHSUNDEEP
swteclipse-rcprcp
Chris Lewold
Chris Lewold

Reputation: 91

Performance Problem with JFace ComboViewer

I need to display "too many" (like 20k) entries in a JFace ComboViewer. Measurement shows, that populating the combo takes multiple seconds, and depending on the UI I have several such combos on the screen - so opening some panels takes > 10 sec. Data to be set are already cached. So it is really not about DB-Loading performance, but just about populating ComboViewer (doesnt matter if I use Combo or CCombo underneath).

I thought about the following, but no solution really seems to work for me.

  1. Use SWT.Virutal. First I thought "that's it", just to find this is only supported for Table and Tree.
  2. Populate content from a background thread. This doesn't seem to work as both Combo and CCombo.setItems only work if invoked from the UI thread.
  3. Populate from a background thread. Split data into Junks. Trigger the UI thread to add each Junk. This seems quite complicated and error prone, but at least an idea I didn't try yet.
  4. Use a different control (ok, which?).
  5. Re-implement ComboViewer to either support SWT.Virtual or at least allow population from another thread but the UI thread. ... here I think this is the solution causing most effort.

I have no obvious other ideas. Did anyone else run into a similar situation, and maybe found a solution to solve it?

I'd love to find a control with a datamodel like e.g. NatTable underneath, which handles "big amounts of data" very well. ComboViewer seems to be the wrong control for such kind of data, but replacing it in an old legacy application again causes quite some work.

Thanks, Chris

Upvotes: 0

Views: 30

Answers (1)

Chris Lewold
Chris Lewold

Reputation: 91

I finally solved the problem like this:

  • Delegate Loading code to a ComboFiller class.
  • ComboFiller delegates loading to a thread (in case a given limit of items is exceeded).
  • The thread splits the items into junks of a given size (I took 1000). It delegates adding each junk back to the UI thread using Display.getDefault().asyncExec().

This way loading "one big set of values" doesn't block the UI thread for multiple seconds; the UI remains useable.

Care has to be taken when setting the currently selected item - this has to be postboned until the loading thread is finished.

I would have preferred to use a concept like SWT.Virtual. Unfortunately the API isn't perfectly consistent between controls.

Upvotes: 0

Related Questions