Re: Efficiency/Reliablility of Scaled Up JTable
On 4/29/13 9:01 AM, Eric Sosman wrote:
On 4/29/2013 11:26 AM, Daniel Pitts wrote:
On 4/29/13 5:13 AM, clusardi2k@aol.com wrote:
If I have a JTable with a lot of colors, and if the application
deletes and then adds columns to it will the performance degrade if I
go from a 30 X 30 table to a 1000 X 100 table, please explain.
Thanks,
It depends on the underlying TableModel implementation. Using the
default implementation, it is backed by a Vector of Vectors [1].
A "random position" insert or remove in a vector is amortized to be an
O(N) operation. insert/remove at the end of a vector is O(1).
Adding a row will create a brand new Vector, and insert that Vector into
the row Vector. remove a row will simply remove that row from the row
Vector.
Adding or remove a column will need to iterate through all rows and
add/remove from each of the column Vectors. If this is the first
column, your worst case, this will be a O(N*M) operation.
[...]
Good stuff. However, didn't the O.P. have a question a day
or so ago about a "horizontally scrolling" table, where new columns
appeared at the right while old ones vanished from the left (maybe
with a few leftmost columns inviolate)?
Perhaps, I skipped over it if that was the case.
If that's the table in
question, I think he'd do better to use a column-oriented model,
where the vectors (not necessarily Vectors) run top-to-bottom
instead of left-to-right. A benefit would be that inserting,
deleting, and permuting columns could be done by I/D/P'ing the
vector references instead of mucking with the individual cell
contents.
That might be a benefit, if indeed the pre-written and well-tested
DefaultTableModel doesn't perform "well enough" for the real use-case at
hand.
It all depends on which axis gets more activity.
It also depends on what minimum performance is necessary, and what the
maximum amount of engineering is allowed to be put into this use-case.
Alternatively, a HashMap<Pair<Integer,Integer>,Object> might
serve as model supporting both access directions equally well,
and could handle row/column rearrangements quickly by storing
"virtual" coordinates translated through a pair of arrays for
the permutation of the moment.>
Supporting Access yes, but imagine now an insert into either the first
row *or* the first column. You now have to go through *every* key of
this hashmap, and build a brand-new hashmap with the adjusted Pair
object (remember, it is a bug to change the value of a Key object). This
increases the number of "worst-case" insertions, and I believe doubles
the average-case cost.
In any case, I suspect that the default model *should* be sufficient.
The OP would do well to write a quick test which plays out some mock
activity to match situations which are expected. The only way to know
for sure is to try. My previous analysis was basically to show that
"you are in the ball-park of being okay".
--
Daniel.