Re: Efficiency/Reliablility of Scaled Up JTable
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