Impact of Dynamic RAM Preview setting on render performance.

Liam_Vegas wrote on 1/17/2005, 12:38 PM
While working through some observations about still-photo rendering times... I uncovered a surprising connection between the settings for Dynamic RAM Preview and the speed at which rendering works for projects with still images.

The basic finding is this. Your Dynamic RAM Preview setting has a HUGE impact on the time it takes to render projects with still images. For best results set your RAM buffers as high as you can.

In my case I infrequently use RAM previewing and normally have it set to 0. This may sound a crazy way to do things... but the reason I do this is because I often use the Boris Graffiti 3.0 titler as a plugin. This product recommends (requires) you set the RAM buffers to zero - otherwise you cannot accurately view the titles on the timeline. The buffering of frames within Vegas does not play well with the way in which BG3 is implemented as a plugin (not sure if that is the fault of Vegas.. or a feature of the way that BG3 is written).

For some still photo rendering this RAM buffer thing made up to a 4 to 1 difference in render times. If your still photoas have a lot of pan/zoom in them - you will likely not see a great deal of impact... but for projects where you may have resized still images once... you will see a huge hit if you do have your RAM buffers at zero.

I doubt that many Vegas editors would encounter quite this problem (as probably only a few use BG3) but I thought this was important enough a finding that I should let the world know anyway.

Now.. .if only there was an easy way to enable/disable RAM buffers (single click script or something) then I would be very happy.

Comments

Spot|DSE wrote on 1/17/2005, 12:51 PM
We had this discussion here a while back, glad someone else is supporting what I've been saying all along. 4 gig of RAM is heavenly, and if you're willing to put up with the hassle of having more than 4, you're even better off. I haven't done a formal test with Pan/Crop enabled, but it seems to be significantly faster there, too. I've got two nearly identical machines, same MOBO, proc, drives, but one has more apps and less RAM than the other. The machine with the 4 gigs screams on still and generated media renders, where the other machine definitely doesn't with only 1 gig.
Liam_Vegas wrote on 1/17/2005, 1:07 PM
Well.. the results are in... thanks to some shared Veg files that Edward Troxel sent me

These are my timings to render with and without Dynamic RAM preview.

.....................0 RAM...........500MB RAM
test1.veg.....2 m 17 s ...... 27 s
test2.veg.....3 m 39 s ...... 32 s
test3.veg......4 m 7 s ...... 4 m 7 s

Test1 had a jpeg still (approx 1600x1200 or thereabouts) which was running for exactly 1 minute on the timeline

Test2 was the same thing but with a single pan/crop keyframe added at the start to resize the image and match aspect ration

test3 was the same again but this time with a keyframe added at the end to force a resize on every frame that was rendered.

The results speak for themselves.

Dynamic RAM preview setting dramatically impacts rendering time for stills! It's not very intuitive this would have such an impact... but there you are!

Thanks again to Edward Troxel for making me see the light!
jetdv wrote on 1/17/2005, 1:50 PM
Liam's table didn't translate well

With dynamic ram preview set to 0
test1.veg 2 m 17 s
test2.veg 3 m 39 s
test3.veg 4 m 7 s

With dynamic ram preview set to 500MB RAM
test1.veg 27 s
test2.veg 32 s
test3.veg 4 m 7 s

Before he discovered this, we couldn't figure out why he was seeing over 2 minutes and I was seeing 20 seconds as the machines were not THAT different in speed.

OdieInAz wrote on 1/17/2005, 2:12 PM
interesting... I took a 5MP JPEG (2.34Mb), put on time line for 1 minute. No pans, zooms just reduce interlace flicker, and BEST rendering. Rendering to MPEG (V4)

Preview RAM: 0MB
Render : 15m 55s

Preview RAM: 1MB
Render : 1m 45s

Preview RAM: 32 MB
Render: 1m 45s

Maybe Vegas uses Dynamic Preview RAM for some sort of scratchpad space when rendering?? Maybe it doesn't need a much
Liam_Vegas wrote on 1/17/2005, 2:17 PM
I doubt that it needs a lot of RAM in these cases - just enough to cache the single frame that it initially renders internally and then spits out in the rendered file.

I had not thought of trying it on MPEG renders but it makes sense that it impacts those as well.

I still think it a <little> odd that such a seemingly benign setting to do with previewing can have an impact on rendering performance.
winrockpost wrote on 1/17/2005, 3:17 PM
Great bit of info, I got a machine that has seemed awful slow lately,, and i am pretty sure I had a demo of boris something or otheron it. And I dont use ram preview, bet i know why its slow.
thanks Liam
Grazie wrote on 1/17/2005, 9:41 PM
Liam! Excellent piece of deductive reasoning based on some absolutes. All this has been helped by having a controlled, checked-out confirmation by Edward. . . Sorry I couldn't spend time on it yesterday. Tad busy!

Yet ANOTHER good reason for this Forum!

My betting is we wont get a definitive answer from Sony on this - yet - soon would be good. I say this because I'm wanting to hear what is going to be done concerning the RAM Preview stumbling on 2 or 3 frames when PAN/CROP is LOCKED to T/L. Did you get the thread on this on?

Ok, some of my thoughts combining you and my experince:

1/- Rendering speeds with Pan/Crop is affected by RAM Preview BUFFER

Result: BAD = 0mb ; GOOD > 1mb


2/- RAM Build Previews are affected by Locked P/C timeline

Result: BAD = LOCKED; Unlock = GOOD

Well, it would appear that two seemingly unrelated functions - RENDERING [ here speeds ] and RAM Previewing [ here getting beyond 2 or 3 frames ] could very well have a "common" causal root: PAN/CROP.

Liam, try this for size. Do you Render these Events with a Locked to T/L Pan Crop, Keyframe timeline? Or is it "Unlocked"? Try both ways and see if the Render speeds are affected?

It was your comment about, "I doubt that it needs a lot of RAM in these cases - just enough to cache " .. .that got me thinking.

My opinion? I think that there is a causal link between P/C and RAM Preview Build/Renders that as yet has not been investigated. My opinion is that P/C "grabs" RAM for previewing and still holds this advantage for itself when rendering and maybe it HAS too. But what do I know?

Oh yes! . . . "I still think it a <little> odd that such a seemingly benign setting to do with previewing can have an impact on rendering performance. " Very polite Liam - HAH!

I'm just looking for the time I don't NEED to copy an Event, which has a P/C Locked Keyframe timeline, further down the Edit T/L JUST to see a RAM built Preview - 'cos that is EXACTLY what it takes to see my work Preview from a RAM Built Preview.

Good work Liam - great support Edward,

Grazie
Liam_Vegas wrote on 1/17/2005, 10:19 PM
Liam, try this for size. Do you Render these Events with a Locked to T/L Pan Crop, Keyframe timeline? Or is it "Unlocked"?

I did this with events unlocked to the timeline (or do you mean with the sync cursor on.. I thought that was the problem you experienced before). Either way.. the sync cursor was not on either.

Who knows where the strange connection points are in this "feature" and let's hope Sony can come up with a slightly better way of representing this functionality.

I'll post a feature request to Sony in any case.
Grazie wrote on 1/17/2005, 10:24 PM
Excellent! Thanks Liam, and yes I did mean, "or do you mean with the sync cursor on." . . now try it ON. See what you get.

Thanks for posting the feature request.

G
rmack350 wrote on 1/17/2005, 10:26 PM
Great thread, folks.

On another thread or two there were some notes about setting the RAM preview too high. Can't remember the specifics except that it was bad to jam your RAM setting to high.

Helpful, aren't I?

Rob Mack
rmack350 wrote on 1/17/2005, 10:47 PM
Spot, I have to ask you about your systems with 4 GB of RAM. How much does Windows actually report is available?

The reason I ask is that I just had to write up an advisory for a PC manufacturing client on this topic. Turns out that in 32 bit systems there's just enough addressing space to address 4 GB of memory, or maybe 3 and a quarter GB (plus or minus) if you add PCI busses and other normal stuff that must also be addressed. (Since these are always present you just can't address the full 4 GB).

Generally, the good options are to either build a system that totally supports 64bit addressing (processor, chipset, OS, BIOS must all be capable), to ignore that anywhere from half a gig to nearly a full gig is missing, or to build the system with 3GB.

All this is based on what I was able to drag out of a handfull of engineers (gregarious chatty people that they are) and a few other advisories relating to servers. I'm curious what you actually are seeing in System Properties.

Even better, if this shows in System Properties, would you send me a screen shot of it at rmack350ATsbcglobalDOTnet?

Rob Mack