Notes on variable-height rows in a JTable
Recently 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.The Premise
To track the heights of each row,
JTable uses a 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 SizeSequence precomputes the answers and stores them in an array.The Problem
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 SizeSequence must 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!Workaround 1
Don't use variable row height
JTables!Workaround 2
Bulk up row changes. Instead of adding rows one at a time, add them ten at a time or better, all at once.
Workaround 3
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.
