Re: Efficiency/Reliablility of Scaled Up JTable

On 4/29/13 5:13 AM, clusardi2k@aol.com wrote:


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.

So, for a 1000 x 100 table:

Best case scenario of deleting the last row is fast constant time operation.

Worst case scenario (deleting or inserting the first column) is 10,000
operations. That is, for each 1000 rows, you need to touch each of the
100 columns.

Now, some estimations... I'm going to estimate that one "operation" (a
reference copy in this case) takes 50 CPU cycles to complete. This is a
high estimate, but may be affected by memory latency and other system
delays. Now, if your processor is at least 1GHz, that means a single
"operation" will take 50ns. 10,000 operations will take 500?s. Human
perception around 250ms, meaning you could do this worst-case update 500
times before a human would even notice that anything was changing.

Next, when you insert/delete a row or column, the UI has to repaint the
"visible" portion of your table. The timing on this is likely going to
be the expensive part of operation. However, if you are only looking at
a 30x30 cell viewport into the table, the performance of this will be
nearly the same regardless of the overall table size.

Hope this helps,
Daniel.

[1]
<http://docs.oracle.com/javase/7/docs/api/javax/swing/table/DefaultTableModel.html>