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

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

Re: Efficiency/Reliablility of Scaled Up JTable

Show all headers | View raw

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.

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