Hi Ivan The thing is in your slower one in red of your example your first copying/shuffling everything to another channel before merging them from their respective channels. The fast one there isn't any shuffling around of channels first. Your going in the opposite direction(shuffling to other channels instead of to rgba). The act of actually moving channels around is what causes the hit no matter which direction your going.
To make the test equal you would need to use generators that allow you to create in a specific channel. The Checkerboard and Colorbars in your example doesn't have this ability. -deke On Mon, Sep 5, 2011 at 23:06, Ivan Busquets <[email protected]> wrote: > Hi, > > Found the script I sent a while back as an example of picking layers in > merges using up more resources. > Just tried it in 6.3, and I still get similar results. > > Script attached for reference. Try viewing/rendering each of the two groups > while keeping an eye on memory usage of your Nuke process. > > Cheers, > Ivan > > > > On Mon, Sep 5, 2011 at 11:42 AM, Ivan Busquets <[email protected]>wrote: > >> Another thing is it sounds like you are shuffling out the channels to the >>> rgb before you merge them. This also does quite a hit in speed. It is far >>> faster to merge and pick the channels you need rather then shuffling them >>> out first. >>> >> >> That's interesting. My experience has usually been quite the opposite. I >> find the same operations done in Merges after shuffling to rgb are faster, >> and definitely use less resources, than picking the relevant layers inside >> the Merge nodes. >> >> Back in v5, I sent a script to support as an example of this behavior, >> more specifically how using layers within the Merge nodes caused memory >> usage to go through the roof (and not respect the memory limit in the >> preferences). At the time, this was logged as a memory leak bug. I don't >> think this was ever resolved, but to be fair this is probably less of an >> issue nowadays with higher-specced workstations. >> >> Hearing that you find it faster to pick layers in a merge node than >> shuffling & merging makes me very curious, though. I wonder if, given enough >> memory (so it's not depleted by the mentioned leak/overhead), some scripts >> may indeed run faster that way. Do you have any examples? >> >> And going back to the original topic, my experience with multi-channel exr >> files is: >> >> - Separate exr sequences for each aov/layer is faster than a single >> multi-channel exr, yes. As you mentioned, exr stores additional >> channels/layers in an interleaved fashion, so the reader has to step through >> all of them before going to the next scanline, even if you're not using them >> all. Even if you read each layer separately and copy them all into layers in >> your script (so you get the equivalent of a multi-channel exr), this is >> still faster than using a multi-channel exr file. >> >> - When merging different layers coming from the same stream, I find >> performance to be better when shuffling layers to rgba and keeping merges to >> operate on rgba. (although this is the opposite of what Deke said, so your >> mileage may vary) >> >> Cheers, >> Ivan >> >> On Thu, Sep 1, 2011 at 1:55 PM, Deke Kincaid <[email protected]>wrote: >> >>> Exr files are interleaved. So when you look at some scanlines, you need >>> to read in every single channel in the EXR from those scanlines even if you >>> only need one of them. So if you have a multichannel file with 40 channels >>> but you only use rgba and one or two matte channels, then your going to >>> incur a large hit. >>> >>> Another thing is it sounds like you are shuffling out the channels to the >>> rgb before you merge them. This also does quite a hit in speed. It is far >>> faster to merge and pick the channels you need rather then shuffling them >>> out first. >>> >>> -deke >>> >>> On Thu, Sep 1, 2011 at 12:37, Ryan O'Phelan <[email protected]>wrote: >>> >>>> Recently I've been trying to evaluate the load of nuke renders on our >>>> file server, and ran a few tests comparing multichannel vs. >>>> non-multichannel >>>> reads, and my initial test results were opposite of what I was expecting. >>>> My tests showed that multichannel comps rendered about 20-25% slower, >>>> and made about 25% more load on the server in terms of disk reads. I was >>>> expecting the opposite, since there are fewer files being called with >>>> multichannel reads. >>>> >>>> For what it's worth, all reads were zip1 compressed EXRs and I tested >>>> real comps, as well as extremely simplified comps where the multichannel >>>> files were branched and then fed into a contact sheet. I was monitoring >>>> performance using the performance monitor on the file server using only 20 >>>> nodes and with almost nobody using the server. >>>> >>>> Can anyone explain this? Or am I wrong and need to redo these tests? >>>> >>>> Thanks, >>>> Ryan >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
