Open dialog performance on Windows

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.


  • 0
    Alan Trombla

    Hi Leo,

    Thanks very much for the constructive criticism and all the testing.  We've put a lot of effort into speeding up the file browser (especially on windows, which seems to somehow always be worse in these cases).  And in particular we do keep stat'ing to a minimum, but the underlying data structures are managed by Qt, so we don't have complete control over them.

    We'll take another pass at improving the specific case you mention in our next release (which should be in BETA testing in a couple of months - let us know at support@tweakadmin.com if you'd like to be added to the BETA mailing list).

    Also, there may be a couple things you can do to improve performance.

    • Try the different modes in the file browser.  In general, Files Detail View should be fastest, but sometimes Column View is better.
    • Try turning off the icon display.  Just click on the "wrench" in the upper right, and choose "No Icons".

    Hope that helps,


  • 0
    Leo Hourvitz

    Hi Alan,

    Thanks for the feedback.  Yes, we'd love to be on the beta program for evaluating these sorts of things.  I can't promise we'll spend tons of time testing the beta on all other features but we can definitely try and verify things on Windows.  I agree, these sort of network file system performance problems always seem to crop up more often on Windows than on Linux (as do the "for some mysterious reason your render job couldn't open this file" problems), but whatcha gonna do?  Switching to Linux is not a realistic proposition for us; we're way too Adobe-app dependent as much as I sometimes wish we weren't.

    I've turned icons off from several months ago, and periodically try one mode vs. the other.  For this issue, I haven't seen any cases where the two modes are dramatically different (Files Detail View can be faster when for some reason you have a ton of files in a ancestor directory somewhere, but that's not typical for us).

    Thanks again for the great tool and looking forward to future even better versions!


Please sign in to leave a comment.