Wasn't it Mike Thorn who wrote:
>Slime wrote:
>> No. They will only slow the *parse* time down by a miniscule amount. Nothing
>> to be concerned about.
>
>If I had a scene in which I used multiple includes (textures.inc, 
>metals.inc, woods.inc and functions.inc, for example), would it be worth 
>my while as far as parse time goes to copy out just the definitions I 
>want into my file and *not* attach the entire include files?

It's easy to perform some timing tests.

On my machine, each additional #include "colors.inc" adds 0.007 of a
second to the parse time. The rendering time and the peak memory used
are not affected.

Here are a few parse times on my machine:

colors.inc      0.007s
textures.inc    0.014s
metals.inc      0.006s
woods.inc       0.009s
functions.inc   0.007s
stones.inc      0.002s

All these include files set marker variables which log the fact that
they've been #included, and the parse time of additional calls is simply
the time it takes to search for the #end that matches the
#ifndef(Colors_Inc_Temp). So the parse time is roughly proportional to
the length of the file. The "stones.inc" file is particularly quick
because it just consists of calls to #include "stones1.inc" and
"stones2.inc" which can be skipped very quickly when searching for the
matching #end.

In some cases, this trick doesn't gain you very much. POV still has to
perform much of the parsing in order to be able to understand the code
well enough to be able to find the matching #end. For example, if I
force "colors.inc" to be really included twice (by undefining
Colors_Inc_Temp) the additional call takes 0.009s instead of 0.007s and
still doesn't affect the render time or peak memory.

If you're desperately short of memory, then there might be some
situations where you might want to declare a stone texture in your own
code to avoid the 193k memory requirement of the first inclusion of
"stones.inc".

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message