Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #23716

Re: Efficiency/Reliablility of Scaled Up JTable

Show all headers | View raw

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.

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>

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Efficiency/Reliablility of Scaled Up JTable clusardi2k@aol.com - 2013-04-29 05:13 -0700
  Re: Efficiency/Reliablility of Scaled Up JTable Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-29 08:41 -0400
  Re: Efficiency/Reliablility of Scaled Up JTable Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-29 08:26 -0700
    Re: Efficiency/Reliablility of Scaled Up JTable Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-29 12:01 -0400
      Re: Efficiency/Reliablility of Scaled Up JTable Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-04-29 13:09 -0700
        Re: Efficiency/Reliablility of Scaled Up JTable Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-04-29 16:52 -0400
      Re: Efficiency/Reliablility of Scaled Up JTable clusardi2k@aol.com - 2013-05-01 12:41 -0700
        Re: Efficiency/Reliablility of Scaled Up JTable Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-05-01 17:52 -0400
        Re: Efficiency/Reliablility of Scaled Up JTable "John B. Matthews" <nospam@nospam.invalid> - 2013-05-02 01:57 -0400
  Re: Efficiency/Reliablility of Scaled Up JTable Robert Klemme <shortcutter@googlemail.com> - 2013-04-29 19:39 +0200
  Re: Efficiency/Reliablility of Scaled Up JTable Roedy Green <see_website@mindprod.com.invalid> - 2013-05-01 10:15 -0700

csiph-web