I  improved the above figure of 75 seconds to 66 seconds by two simple tricks.

I first observed that Poser wants to write every texture it reads before it switches to the rendering engine into it's "PoserTextureCache" folder. In this case the amount of data written is around 1,1Gb (Poser writes ALL the texture data to .exr file format probably because FireFly wants it that way). Poser also behaves very stupidly in this ... if it encounters multiple instances of the same texture file (like in this case "KateShoes" and "KateShirt" etc, it just writes the file again ... and again... and again. That's why you may see some texture files disappear quickly from the "Loading textures" phase and some seem to stay there forever.

Okay. Writing 1,1Gb creates a small amount of i/o traffic. Not enough to choke i/o operations (at least on my system) since the actual process that writes the files is a single thread and even if the disks and busses could take more load, Poser just isn't pushing them to the limit. Nevertheless taking that into notice, I shaved a few seconds by pointing the texture cache to a RAM disk (actually a "tmpfs" filesystem in Linux, but I suppose it's a RAM disk in Windows). That pretty much eliminates any i/o overhead caused by writing the said 1,1Gb.

Next in the general preferences tab the default values for "Memory limit buffer" and "Adaption threshold" are not optimised for my system (I did a fresh P7 install just for this benchmark since I had already deleted most of the needed resources required by the pz3). So I went to the upper limit and put 2047 as the "Memory limit buffer" and "0" as the adaption threshold. With these two things ... over 10% total speed increase.

Normally I wouldn't want to use RAM as the renderer's texture cache because of the obscene file sizes of .exr images.