So artists here are extremely relucatant to use RV because it takes ages to launch these days. I’d say anwyhere between 5-20 seconds with not much happening in the RV_SUPOORT_PATH. A colleague of mine and I just tested this during a screen sharing session and his RV on windows and mine on Linux took about 10-15 seconds to open.
I am not able to convince the artists here to use RV over DJV because of this, so they are all missing out on live review and Shotgrid integration.
RV hasn’t been extensively profiled but I know our storage and other factors are adding to our overhead on launch times, in general it’s not fantastic. Though I would say that the browser integration and navigating that is the main issue as that is a per click / query downtime as opposed to the launch 1 off time. I’ve had reports of people preferring the in browser streaming option over loading data off disk via RV with all the nice packages and pipeline tools we have available for them…
I can relate to your frustrations with trying to get artists to adopt it over other means, if only those artists did what was good for them!
Definitely installing it on a NVME creates a huge difference but yes… its slow…
I would say at most studios I’ve worked I made it a habit of launching RV once and not closing the session as usually whatever version I wanted to play from Nuke or the Asset Manager would then load in my existing RV session.
This is also once how I found out the project I worked on had Audio dailies, as I was listening to music and kept hearing someone talk through it and wondered why I was hearing this looping audio…
Never had a problem with RV startup times. (MacPro 10.13). Takes about 2 seconds from the shell, the web interface or the little python button we added to our read/write nodes in nuke Maybe some other thing in the environment? (OCIO etc.)
Hey Frank!
I just did a little test here, and see that we get similar start times (around 14 secs, from hitting enter until the image pops up - a big seq obviously takes longer to full load). But running with “-nopackages” reduces the start time to a couple seconds or less. It’s clear that the packages are slowing launch times down, but short of walking through all the packages one at a time, it’s hard to tell if it’s one, two or many. Of course, the packages we use make rv worth using, so it’s not practical to run without them. Maybe we need a future suggestion list to add some way to compile packages into a binary that loads quickly?
Honestly though, 15 seconds is really too long?
Thanks @jrab for confirming. I agree, the fact that it’s faster without packages is kinda moot, though what it does tell me is that I should really tidy up some of those.
But yeah, it would be fantastic to see an effort that makes RV launch faster with packages.
I had the same frustration before I worked at Autodesk, so my first meaningful work was to add package load times to -flags ModeManagerVerbose
That’ll let you see the impact of each package. Python is particularly slow at loading packages over a network drive, so all your imports add up; deferring imports until actually needed is a good way to mitigate that.
(for the record, I’m no longer at adsk, but that little timer has saved so much pain).
While not specific to RV, its really only obvious for programs that load frequently while the user is waiting (like RV). Depending on how you load your packages, reducing your PYTHONPATH is important as well, as this compounds how many synchronous file system stats have to be made.
This is a good optimization to make even for things that aren’t running interactively. Imagine if every job on your farm (especially the “short ones”) saved X seconds of startup time and reduced that kind of impact on your filer.
With RV, you have the added benefit of not all tools getting run on every session. While Python best practices for style often dictate otherwise, burying your lesser used package imports into the places where they are used is one way to decrease waiting time for RV startup, and defer that waiting for only the first time someone uses a tool or function that requires it.
Setting packages to deferred load rather than immediate are useful to. If they are mode-like (like annotations) you can specify a menu and shortcut to activate the mode in the package yaml file. This allows RV to not even touch the python file until it is asked for by the user. If you get super-fancy, the shortcut doesn’t even need to be a hotkey, it can be a custom internal event that another package can call.
Lots of good tricks for getting your load times down, I’d probably start in this order:
Profile what is taking so long (see my prior post)
Reduce PYTHONPATH if you have lots of extra locations.
Reduce or defer imports of costly modules to where they are needed.
Make any package that can defer load no longer immediate load.
Maybe some other thing in the environment? (OCIO etc.)