RAM preview settings effect on render speed

scissorfighter wrote on 1/4/2010, 5:35 PM
Hey gang. This complaint (and others like it) seems to keep cropping up here and there in the forum, and I've yet to see a satisfactory answer. I'm seeing a tremendous performance drop in the 64-bit version of 9.0c, as compared to the 32-bit version. I've been doing renders of a 60-minute project with multiple tracks, layers, and so forth, to DVDA-compatible MPEG2 streams. The 32-bit version does the job in 20:18. The 64-bit version does the job in 1:24:30. That's right... FOUR TIMES longer. Same project, same render settings, same hard drives, same CPU, yadda yadda yadda. The only difference is 32-bit vs. 64-bit.

Or so I thought.

Then I checked the "number of render threads" and "RAM preview" settings. The 32-bit version was set to 4 render threads and 32 MB RAM. The 64-bit version was set to 16 render threads and 3000 MB RAM. The system hardware specs are Core i7 quad-core CPU with 6 GB RAM. So I changed the 64-bit version RAM preview settings to 32 MB, and viola, 22 minutes to render. WTF?

Why does the amount of RAM dedicated to RAM preview have such a drastic effect on rendering, particularly when not fully utilizing the amount of available system RAM? With the RAM Preview setting down at 32 MB, there were 4 GB of free RAM available during the render; but even when I had set the RAM preview to 3000 MB, there were still 2 GB of RAM free.

I guess the lesson here is to make sure your RAM preview settings are tiny before you render. Now I'm wondering what else it may impact. Preview window FPS perhaps?

Comments

Rob Franks wrote on 1/4/2010, 7:20 PM
"but even when I had set the RAM preview to 3000 MB, there were still 2 GB of RAM free. "

If you have 6 gig ram then there isn't 2gig left. If 3 gig are reserved for ram preview... maybe a 1/2 or 3/4gig total for Vegas and associated programs, a gig or so for Windows, services, startup programs as well as other programs that may reserve memory... blah, blah... you don't really have much of anything left.

To top it all off there is no reason at all to be reserving that much ram while rendering. I usually crank the crap out of the preview ram during edit because that's when I need it... but then cut it right back when it's time to render. It's a lot of wasted ram otherwise, and as you've noted... it slows the system down.
rmack350 wrote on 1/4/2010, 10:54 PM
Preview RAM is used to cache frames into RAM. The frames get cached automatically while you play the timeline. They also get cached when you manually do a RAM preview. These frames are, as far as I can tell, uncompressed video.

When you do a render to disk Vegas may use the cached frames from RAM and a short render might go very fast. However, once those frames have been used up the render drops down to a more realistic speed.

The problem here is that the preview RAM doesn't get released for Vegas to use while rendering, so in this example you're looking at a computer with half the RAM tied up in Vegas' RAM preview. As Rob is saying, you only have 3GB left for the entire system.

A lot of HD video formats seem to cause Vegas to gobble up tons of RAM so starting out a render with a low RAM preview setting frees up memory for Vegas to use as needed.

Probably the most telling gauge of available usable RAM is to watch the size of the page file. If the page file is growing during a render then you don't have enough RAM available for the job. This will definitely slow down a render.

Watch the size of the page file. This is more informative than the listing of available RAM.
CClub wrote on 1/5/2010, 8:53 AM
What's the easiest way to monitor page file (Windows 7 here)?
wilvan wrote on 1/5/2010, 12:04 PM
Well , got a double Nehalem Xeon station here with 24 Gigs RAM and vista64.
Nothing else running than vegas and strict required and minimum processes running in vista64.

Noticed that when rendering after having done some small minor unimportant things in vegas , it starts rendering at 100 % processor power for the first few seconds and then drops ( till end , about 1 hour m2t video ) to 25% only , resulting in ( too ) long render time.

Simply reboot station , start vegas , load file , do nothing and render same -> 100 % processor power till end ( and normal fast ).

Above can be repeated forever ( RAM more than sufficient )

Same when rendering for second time an mp3 into an ac3 file -> always a glitch in beginning of ac3 file .
Reboot and render same first time -> no glitch
Render exactly same second time -> glitch
Reboot and render same first time -> no glitch
etc... etc...

Never seen in vegas 7 or 8 , am using 9.0c for latest work.
From now after having done the field work and before rendering :
I always reboot ( stupid but unfortunately only right way )

Sony  PXW-FX9 and 2 x Sony PXW-Z280  ( optimized as per Doug Jensen Master Classes and Alister Chapman advices ) and Sony A7 IV
2 x HP Z840 workstations , each as follows : WIN10 pro x 64 , 2 x 10 core Xeon E5-2687W V3 at 3.5 GHz , 256 GB reg ECC RAM , HP nvidia quadro RTX A5000 ( 24GB ), 3 x samsung 970 EVO Plus 1TB M.2 2280 PCIe 3.0 x4  , 3 x SSD 1TB samsung 860 pro , 3 x 3TB WD3003FZEX.
SONY Vegas Pro 13 build 453  ( user since version 4 ) , SONY DVDarch , SONY SoundForge(s) , SONY Acid Pro(s) , SONY Cinescore ( each year buying upgrades for all of them since vegas pro 4 )
(MAGIX) Vegas pro 14 ( bought it as a kind of support but never installed it )
SONY CATALYST browse 
Adobe Photoshop  CC 2025
Adobe After Effects CC 2025 & Adobe Media Encoder CC 2025
Avid Media Composer 2025.xx ( started with the FREE Avid Media Composer First in 2019 )
Dedicated solely and only editing systems , fully optimized , windows 10 pro x 64 
( win10 pro operating systems , all most silly garbage and kid's stuff of microsoft entirely removed , never update win 10 unless required for editing purposes or ( maybe ) after a while when updates have proven to be reliable and no needless microsoft kid's stuff is added in the updates )

rmack350 wrote on 1/5/2010, 5:42 PM
That's interesting. I don't know if it's relevant but one thing that happens on a reboot is that the preview RAM is most assuredly flushed. I take it shutting down Vegas and then restarting isn't enough?

I've always wondered if, since Vegas caches things into the preview RAM automatically, if it's also trying to cache while you render. If the preview window is showing your progress as you render then there's something there to cache. Seems like it shouldn't do that but it's hard to know if it does or doesn't.

I don't know how to watch the page file usage in Win7. In XP it's shown in the task manager along with CPU usage.

Rob
FilmingPhotoGuy wrote on 1/5/2010, 9:57 PM
Where exactly do you set the "Preview Ram"? If I right click the preview window the option "Adjust the size and quality........" option is greyed out.
MarkWWW wrote on 1/6/2010, 9:02 AM
> I don't know how to watch the page file usage in Win7.

Microsoft keeps changing the terminology it uses to describe these things, confusing the issue considerably. But as far as I can make out, in Windows 7 they have gone back to calling it "Commit Charge" or just "Commit" rather than "Page File" or "Page File Usage" as they have in previous versions. There's some useful information in one of Mark Russinovich's Blog here about memory handling in Windows, including the way various versions of Windows name and display these things, and he also has a nice free tool called Process Explorer which, amongst all its other useful investigative features, contains a window showing a superset of the memory/CPU information displayed in the various versions of Task Manager - in the terminology he uses the "Commit History" graph is the one to watch.

Or if you just want to use the inbuilt tools in Win7, the "Commit Charge" graph on the Resource Monitor Memory tab is the one. Some more useful information here.

Mark