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

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

Re: Efficiency/Reliablility of Scaled Up JTable

Show key headers only | View raw

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)?  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.

     It all depends on which axis gets more activity.

     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.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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