Notes on variable-height rows in a JTableRecently Sun hosted a developer web chat, Getting High Performance from Your Desktop Client. I decided to ask about a problem I faced a few months ago: performance of JTables with variable-height rows.
To track the heights of each row,
SizeSequence. This class stores the height of each row in pixels, plus it includes helper methods to answer common questions, "What row belongs in pixel P?" and "What's pixel range for row R?". To make answering these questions snappy, the
SizeSequenceprecomputes the answers and stores them in an array.
Suppose we add, remove or change the height of a row in our
JTable. Now our
SizeSequence's answers array is out of sync. Unfortunately the
SizeSequencemust recalculate the entire answers array. For a table with R rows, this will require R operations!
The Problem Multiplies
Suppose our table is populated one row at a time. This will be the case for all applications where the rows are streamed or filtered. Now this is R changes, each one requiring R operations to update the
SizeSequence. For a table with R rows, this will require R2 operations!
Don't use variable row height
Bulk up row changes. Instead of adding rows one at a time, add them ten at a time or better, all at once.
Go have a coffee and wait for Sun to resolve issue 6231057. This should shorten the cost of a row change from R operations to a much more tolerable log2R.