We were looking at a schema that had 10k+ tables on it and we noticed a substantial decrease of performance while loading the tables and after they are loaded and we try to scroll over them.
Not overly surprising.
After some search on the web we found a post of the ACITree maintainer here and he states that the library was not meant to handle that amount of data.
Still, with whatever optimizations I'll be able to implement, 10k items seem allot on one level. On a slow hardware you'll still have to wait enough to get them created, scrolling will also be a problem ... I think.
Is it a common scenario to have an extremely large number of tables?
Not really.
We wanted to bring up this issue to solicit ideas for ways to improve the performance of large lists of tables in the ACITree.
We discussed replacing ACITree in the past. That's still an option of course, though I've yet to find anything better.
A more generic solution might be to group tables if there are more than N - e.g. add an extra level into the hierarchy dynamically splitting them up into groups (which would probably also have to be dynamically defined to allow for non-ascii naming) like A-D, E-H etc.