POV-Ray : Newsgroups : povray.advanced-users : Macro load optimization Server Time
1 Nov 2024 01:20:46 EDT (-0400)
  Macro load optimization (Message 1 to 5 of 5)  
From: CShake
Subject: Macro load optimization
Date: 5 Sep 2009 11:44:00
Message: <4aa28740$1@news.povray.org>
I understand that whenever a macro is called that is not in the main 
scene file, the .inc must be opened for every call, thus the speed 
improvement by copying often used macros to the scene file.

However, how is it handled when a macro calls another macro?

Example:
scene.pov has no macros defined, includeA.inc has MacroA defined.
Scene calls MacroA 100 times, so includeA.inc is opened and closed 100 
times.

scene.pov has no macros defined, includeA.inc has MacroA and MacroB defined.
Scene calls MacroA 100 times, and MacroA then calls MacroB 10 times 
within itself.
My question: Is includeA.inc opened 100 times still, or is it then 
opened 1000 times?


Post a reply to this message

From: Alain
Subject: Re: Macro load optimization
Date: 5 Sep 2009 17:42:51
Message: <4aa2db5b$1@news.povray.org>

> I understand that whenever a macro is called that is not in the main 
> scene file, the .inc must be opened for every call, thus the speed 
> improvement by copying often used macros to the scene file.
> 
> However, how is it handled when a macro calls another macro?
> 
> Example:
> scene.pov has no macros defined, includeA.inc has MacroA defined.
> Scene calls MacroA 100 times, so includeA.inc is opened and closed 100 
> times.
> 
> scene.pov has no macros defined, includeA.inc has MacroA and MacroB 
> defined.
> Scene calls MacroA 100 times, and MacroA then calls MacroB 10 times 
> within itself.
> My question: Is includeA.inc opened 100 times still, or is it then 
> opened 1000 times?

No.
The source file is only opened and closed when you call it from another 
file.
Also, if a macro from an include file calls a macro from the main file 
or another include from whithc it was called, then NO file gets to be 
open/red/closed.

Call a macro from the SAME file = no additional file transaction.
Call a macro from a file upper in the calling list = still no additional 
file transaction.
Example 1: A macro from an include file use a macro from the main file.
Example 2: A macro from an include file, included by another include 
file, that use a macro from the preceding include (the one that caused 
it's inclusion).


Alain


Post a reply to this message

From: clipka
Subject: Re: Macro load optimization
Date: 6 Sep 2009 03:17:03
Message: <4aa361ef$1@news.povray.org>
CShake schrieb:
> I understand that whenever a macro is called that is not in the main 
> scene file, the .inc must be opened for every call, thus the speed 
> improvement by copying often used macros to the scene file.
> 
> However, how is it handled when a macro calls another macro?

As long as a macro is called from whichever file it is defined in - 
whether it is the main scene file or an include file - there is no file 
opening/closing overhead involved.


Post a reply to this message

From: CShake
Subject: Re: Macro load optimization
Date: 8 Sep 2009 13:27:35
Message: <4aa69407$1@news.povray.org>
Alain wrote:
> The source file is only opened and closed when you call it from another 
> file.
> Also, if a macro from an include file calls a macro from the main file 
> or another include from which it was called, then NO file gets to be 
> open/read/closed.
> 
> Call a macro from the SAME file = no additional file transaction.
> Call a macro from a file upper in the calling list = still no additional 
> file transaction.
> Example 1: A macro from an include file use a macro from the main file.
> Example 2: A macro from an include file, included by another include 
> file, that use a macro from the preceding include (the one that caused 
> it's inclusion).
> 
> 
> Alain

Thanks, didn't know about the hierarchy part for not opening files 
higher in the chain.

One further question:
The main file includes IncludeA and IncludeB. IncludeB has a macro which 
uses a macro from within IncludeA.

//-----main.pov
#include "A.inc"
#include "B.inc"

MacroB(param)
//-----end main.pov

//-----A.inc
#macro MacroA(param) //stuff
#end
//-----end A.inc

//-----B.inc
#macro MacroB(param)
   //stuff
   MacroA(param)
#end
//-----end B.inc

What is the file I/O done in this case?

Chris


Post a reply to this message

From: Alain
Subject: Re: Macro load optimization
Date: 8 Sep 2009 19:14:14
Message: <4aa6e546$1@news.povray.org>

> Alain wrote:
>> The source file is only opened and closed when you call it from 
>> another file.
>> Also, if a macro from an include file calls a macro from the main file 
>> or another include from which it was called, then NO file gets to be 
>> open/read/closed.
>>
>> Call a macro from the SAME file = no additional file transaction.
>> Call a macro from a file upper in the calling list = still no 
>> additional file transaction.
>> Example 1: A macro from an include file use a macro from the main file.
>> Example 2: A macro from an include file, included by another include 
>> file, that use a macro from the preceding include (the one that caused 
>> it's inclusion).
>>
>>
>> Alain
> 
> Thanks, didn't know about the hierarchy part for not opening files 
> higher in the chain.
> 
> One further question:
> The main file includes IncludeA and IncludeB. IncludeB has a macro which 
> uses a macro from within IncludeA.
> 
> //-----main.pov
> #include "A.inc"
> #include "B.inc"
> 
> MacroB(param)
> //-----end main.pov
> 
> //-----A.inc
> #macro MacroA(param) //stuff
> #end
> //-----end A.inc
> 
> //-----B.inc
> #macro MacroB(param)
>   //stuff
>   MacroA(param)
> #end
> //-----end B.inc
> 
> What is the file I/O done in this case?
> 
> Chris
Every time that the macro from B.inc is called, B.inc need to be 
accessed. Then, every time that macro uses the macro from A.inc, A.inc 
will get accessed.

So, each time that MacroB() is used, you'll end up accessing BOTH includes.

MUCH beter to copy MacroA() into B.inc or the main file.


Alain


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.