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