It has been some time since we optimized for large databases. So some changes might have crept in that are a disaster on large databases.
Are you trying trunk or gramps34? They are quite different at the moment.
To speed things up:
1/remove calculated columns, like spouse, ... You can do that in the preferences of the view (icon on toolbar or in menu)
2/make sure the status bar does not compute relationship, or if it does, that it does not scan too many generations back
3/make sure you don't have gramplets that change on change of active person. This can really slow things down, as the gramplet is recomputing on selection of another person in the person view. Especially a descendant gramplet and such can be problems.
We have had in the past a large .gramps to test with, but that was generated data, so behaves differently from real genealogical data. I don't have a large dataset to try with at the moment.
As you post on the devel list, can you code yourself? To understand where the bottleneck is, we need to add profiling on the searching, see
On trunk, the import statement for that has changed however. Let us know if you are interested in profiling it.
Apart from the above, for large datasets, another view which is not a listview would not be bad. A listview after all needs to load a lot of data in memory. Typical view within companies is then a search view, where you give some limitations, and only that piece is obtained from the database, instead of the entire table. It would not be a bad addition to gramps to create such a view.