I looked back at some TableMatrix code that I did awhile ago. At times this code works with a matrix of 5,000+ x 12 other times just 1 x 12. A few conclusions/tips I came up with:

1. I put a few blank lines (rows) at the end of the matrix. As the matrix gains more rows, the little scrolling handle becomes smaller and more "twitchy". Also as this the scrolling handle gets smaller, you may have to get "underneath it" with the mouse instead of "on top of it". You've probably already noticed this. So for larger tables, it can be hard to determine that you are actually at the end of data unless there are blank rows there to alert the user (i.e. is the scolling gizmo as far down as it's going to go or not?).

2. I don't have a fixed number of rows, I use as many are need for a particular dataset and vary this dynamically. The very large number of rows are outlier cases in my app, most tables are less than 500-1,000 rows and are easier for the user to scoll through than the big ones because of the previous point.

3. I did some performance testing because I was worried about making hash'es with 50-90,000 keys. You can pre-size a hash like: keys(%hash)= 8192; which starts %hash off with space for 8192 keys instead of starting with 8 and growing from there. It turned out that this didn't matter much in my application. I decided that there was no need to pre-size the hash or initialize it. However I did find out that something like your clear_table() did amount to something! I guess this is a deal where 2x "not important" can wind up being important!

What I wound up doing to display new data in an existing table was:
$table->selectionClear('all'); Could be that setting %hash=() does same thing.
-This zaps row zero which are column heads so I just have a sub that fills in that part of hash table.
-Then I just add keys to the hash as needed for each row.
-fill in some blank lines, then call $table->configure(-rows => $size); with the new size (includes the "blank" lines).

Anyway messing with the table's data hash does not affect the $table object and it doesn't have to be re-created. As the table matrix gets "big enough" (depends on lots of things), performance can become an issue. I violate the object's "data encapsulation" by messing with the hash directly to get the requisite performance.

Have fun, TableMatrix with its hash table data structure worked out better than I would have predicted when I started. "re-starting" the table with default hash table key size of 8 didn't seem to matter, your mileage may vary, but a single statement as shown above will fix that if its a problem.