On 5/6/21 6:37 AM, ingo wrote:
> in news:firstname.lastname@example.org jr wrote:
>> $povray foo.pov +o/tmp/foo
> But that means you also have the final image in ram?
The final written image too, yes. I like Ingo typically work on ram
disk. Everything is faster - if you have the ram for what you are doing
- and you bang on your physical disk(s) a lot less.
I hope Jérôme will double check me here, but there are two types of file
'disk caching' in play.
An image buffer which is already in ram up to some size (200mb?) which
can be set larger by option. The image file ends up on disk in one go at
the end being written from that image buffer.
We have too the continuation state file which I believe is indeed always
on disk (unless your disk is a ramdisk). Partly, I suspect it's because
this file is harder to cache in structure. It's software, so yeah,
expect it could be maintained in ram. It would be another large file in
memory and for those with limited ram (Raspberry PIs for example) this
starts to become an issue if you always do it.
An issue with v3.7 is the continue trace cannot be turned off (-cc /
Create_Continue_Trace_Log=no). This was one of the first things added to
v3.7+ after v3.7 was released. Would caching that file matter as much if
you could just turn off the state caching altogether as you can in v3.8?
I second your thought not enough detail about the caching got into the
documentation. At least, I've never run across it - those beta change
notes are there, but that is not where most will look for documentation
of the output file caching.
Post a reply to this message