This isn't a bug, but it's a huge impediment to using RV.
On Windows when using a network file system, if the number of files in a directory gets large (>500), the time to bring up the RV Open Dialog gets completely unreasonable (5 minutes being a recent experience). Combined with the fact the RV remembers the last directory (which is generally a feature), this makes for a slow workflow.
Here's an example. We have some 250-frame shot on disk with beauty, AO, depth, normal, etc. all in one directory (yes, ideally we would have subdirectories but with ctrl.shaders that's hard to arrange) so there are 2500 files in the directory. So in order to check the shot, we browse to that directory in RV's Open panel. When we open that directory in the open dialog, we wait quite some time, up to several minutes depending on the network performance (by the way, it's the same result whether we use File Details View or Column View). Then we open the shot, check the shot, all good (RV caches the images perfectly fast once we can finally click "Open"). New Session, time to open the next shot. File>Open and aww, you wait *again* because RV is still remembering the big directory from the previous shot and insists on displaying it again before allowing us to browse to a different location.
Obviously, our network performance isn't your problem per se, but if you do os.listdir() of that directory in Python, it's instantaneous. So, I'm guessing that RV is actually calling stat() or its equivalent on every file in the directory for some reason, perhaps to determine whether it's a file or a directory. The amount of time RV takes to display the directory is very similiar to the time it take in a script to call stat() on every file in the directory.
The request here is, "speed up the performance of the Open dialog". Specifically, if indeed RV is calling stat() on every file, the suggested solution would be to not do call stat if the file's name ends with a known image file suffix. That should be able to speed up the dialog by an order of magnitude without losing any functionality. My apologies if I'm off base about the cause of the performance problem, I'm just mentioning it because it's a problem I've seen in programs I've implemented in the past.
