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

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

Re: Efficiency/Reliablility of Scaled Up JTable

Show all headers | View raw

On 4/29/2013 4:09 PM, Daniel Pitts wrote:
> On 4/29/13 9:01 AM, Eric Sosman wrote:
>> [...]
>>      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.

     I don't think there's any really slick way to insert a new
cell in the middle of the grid and shove the neighbors rightward
and downward, nor (dually) to delete a cell and pull the neighbors
leftward and upward.  But if all he needs to do is insert or delete
an entire row or column, that's what the permutation arrays (or
lists) are for.  Somebody wants to access row r, column c, and you
look in the HashMap for coordinates rowmap[r],colmap[c] instead.
To insert a new row at the r'th position, copy rowmap[r] through
rowmap[n-1] to rowmap[r+1] through rowmap[n], store a brand-new,
previously unused coordinate value in rowmap[r], and off you go
with the existing HashMap keys unchanged.

     Mind you, I haven't actually *done* this for a TableModel, and
there may be kinks and snags I haven't thought of.  Seems like an
approach that wouldn't penalize one axis to favor the other, though.

> 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".

     Agreed: Measure, measure, measure beats guess, guess, guess.

-- 
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