Speeding up the loading of a JComboBox

[HP News Feed]

I have seen various discussion entries about the poor performance of the
JComboBox additem method when there are a large number of items in the
control.

The proposed route to improvement is invariably to use a
DefaultComboBoxModel and then create the JComboBox control using the
constructor that uses the Model. e.g.

Vector v = new Vector(numItems);
for (int i = 0; i < numItems; i++) {
v.add(new Integer(i));
}
DefaultComboBoxModel model = new DefaultComboBoxModel(v);
JComboBox box = new JComboBox(model);

I support an application that is showing symptoms of this problem, and I
have experimented with the above technique, and it appears to work well.
However, I want to be able to re-populate the item list of an existing empty
JComboBox i.e. I do not have the opportunity to invoke the model
contstructor while creating a new JComboBox. Instead I have used the
setModel method. e.g.


private void populateCombo(int numItems)
{
Vector v = new Vector(numItems);
for (int i = 0; i < numItems; i++) {
v.add(new Integer(i));
}
DefaultComboBoxModel model = new DefaultComboBoxModel(v);
box.setModel(model);
}

I am a newcomer to java and want to ask if the above is a legitimate
approach. e.g. Will the java garbage collection capabilities properly take
care of the fact that a new DefaultComboBoxModel is created on every call to
this method ? Will loading it in this way alter it's dynamic behaviour
later in it's life (e.g. the firing of events as the list is navigated and
items are selected).

Thanks,

Steve Shadbolt, HP UK
Remove hat to reply

 

[Michael Rauscher]

I have seen various discussion entries about the poor performance of the
JComboBox additem method when there are a large number of items in the
control.

JComboBox just delegates the message down to its model. So the problem
has to be located there.

The proposed route to improvement is invariably to use a
DefaultComboBoxModel and then create the JComboBox control using the
constructor that uses the Model. e.g.

Who proposed this? I'd suggest to not use DefaultComboBoxModel at all.
It uses Vector and Vector is slow due to synchronization.

I support an application that is showing symptoms of this problem, and I
have experimented with the above technique, and it appears to work well.
However, I want to be able to re-populate the item list of an existing empty
JComboBox i.e. I do not have the opportunity to invoke the model
contstructor while creating a new JComboBox.

Use your own implementation of ComboBoxModel. Implement a method
setData, an add method that is able to add complete collections etc.,
then you don't need to create a new model object every time.

Bye
Michael

 

[HP News Feed]

Who proposed this? I'd suggest to not use DefaultComboBoxModel at all. It

uses Vector and Vector is slow due to synchronization.

The proposal came from here :
http://java.sun.com/features/2002/03/swinggui.html

I am not actually using a Vector - this just came from the example. Mine
uses a List. I will take a look at your suggestion of implementing my own
ComboBoxModel. I am still interested in the legitamy of my original
proposal though.

Thanks,

Steve.

 

[Michael Rauscher]

The proposal came from here :
http://java.sun.com/features/2002/03/swinggui.html

This is just an example. No one proposed to use a DefaultComboBoxModel.
The key statement is to "perform operations in bulk to reduce the number
of events that are posted". This is independent of the model class one uses.

The statemenent "construct a new one instead of reusing the existing
one" that is given in this paper is valid only for models that don't
have the ability to replace the contents - like DCBM. Have a look at
DefaultTableModel (which also uses Vector). There's a method
setDataVector where one can replace the whole table contents.

I am not actually using a Vector - this just came from the example. Mine
uses a List. I will take a look at your suggestion of implementing my own

If you use DCBM then you use a Vector as DCBM uses a Vector.

ComboBoxModel. I am still interested in the legitamy of my original
proposal though.

The setModel approach is correct. If the model can't replace data it's
the only correct way. Of course, the garbage collector will properly
take care of the fact that you create new objects all the time. You can
call box.setModel(null) in advance to release the old model. Loading
this way won't affect the dynamic behaviour.

Bye
Michael

 

[Michael Rauscher]

You can
call box.setModel(null) in advance to release the old model.

Delete this. Of course, you can't set the model to null...

 

[Joan]

Delete this. Of course, you can't set the model to null...

But you can set the Layout Manager to null <g>

 

[Michael Rauscher]

But you can set the Layout Manager to null <g>

???

I wrote the above with respect to garbage collection.

Bye
Michael

 

[Andrew Thompson]

???
I wrote the above with respect to garbage collection.

Hence the <g>.

I think that pun was more directed at folks that might
whine and complain every time someone sets a layout to
null, ..or about the quality of GUI advice delivered on
c.l.j.p.

Made me laugh!