Hello. I am doing a scene that calls on various INC files for various
object. Each inc file starts with #include "colors.inc". Wil all these
calls from sepparate files slow the render down?

Post a reply to this message

> Hello. I am doing a scene that calls on various INC files for various
> object. Each inc file starts with #include "colors.inc". Wil all these
> calls from sepparate files slow the render down?


No. They will only slow the *parse* time down by a miniscule amount. Nothing
to be concerned about.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Barehunter nous apporta ses lumieres ainsi en ce 2004-12-21 21:35... :

>Hello. I am doing a scene that calls on various INC files for various
>object. Each inc file starts with #include "colors.inc". Wil all these
>calls from sepparate files slow the render down?
>
>
>  
>
colors.inc, as well as just about every "standard" inc files have a test 
to ensure they are only effectively included once in any scane. It test 
for the non-existance of a variable, if it don't exists, it create it 
and proceed with the bulk of the file.

Alain

Post a reply to this message

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?

~Mike

Post a reply to this message

> 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?


I wouldn't think that it would take that long to parse. If I were you, I'd
go ahead and use as many include files as I needed, and if I *noticed* that
it was taking an annoyingly long time, then I'd consider copying only what I
needed into my file. Of course, if you do that, then you have to keep in
mind that you can't rely on changes (bug fixes or improvements) to the
macros you use in the future.

So, don't do that unless you really have to.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Alain wrote:
> Barehunter nous apporta ses lumieres ainsi en ce 2004-12-21 21:35... :
> 
>> Hello. I am doing a scene that calls on various INC files for various
>> object. Each inc file starts with #include "colors.inc". Wil all these
>> calls from sepparate files slow the render down?
>>
>>
>>  
>>
> colors.inc, as well as just about every "standard" inc files have a test 
> to ensure they are only effectively included once in any scane. It test 
> for the non-existance of a variable, if it don't exists, it create it 
> and proceed with the bulk of the file.
> 
> Alain
Right but you have to code for it:

#ifndef(Colors_Inc_Temp)
   #include "colors.inc"
#end

Post a reply to this message

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

>> colors.inc, as well as just about every "standard" inc files have a 
>> test to ensure they are only effectively included once in any scane. 
>> It test for the non-existance of a variable, if it don't exists, it 
>> create it and proceed with the bulk of the file.
>>
>> Alain
> 
> Right but you have to code for it:
> 
> #ifndef(Colors_Inc_Temp)
>   #include "colors.inc"
> #end

No, this test is *inside* colors.inc.

-- 
ZeSly
http://perso.wanadoo.fr/zesly/

Post a reply to this message

ZeSly <zes### [at] nonenul> wrote:
> > #ifndef(Colors_Inc_Temp)
> >   #include "colors.inc"
> > #end

> No, this test is *inside* colors.inc.

  But putting the test around the #include is more efficient because
if Colors_Inc_Temp was defined, the "colors.inc" file will not even
be opened, much less parsed through.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message