Perhaps a lazy question, I skimmed the docs couldn't find anything on this:

I recall something being said here about the relationship of macros and 
#include files.  As I recall there can be some inefficiency if a 
frequently called macro resides in a separate file and '#included' by 
the file doing the calling?  That it is better for it to be resident in 
the file from which it is called.  I seem to recall it has something to 
do with memory use?  Anyway I am trying to figure out how this affects 
things in compounded situations.

For instance what if I have a macro in an #included file but it is only 
called once.  But IT calls a second macro multiple times.  Where is it 
best to have the second macro reside?  Is there any advantage to having 
it in the primary file or is it inefficient, no matter what, since it is 
called from the #include file?

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> I recall something being said here about the relationship of macros and 
> #include files.  As I recall there can be some inefficiency if a 
> frequently called macro resides in a separate file and '#included' by 
> the file doing the calling?  That it is better for it to be resident in 
> the file from which it is called.  I seem to recall it has something to 
> do with memory use?  Anyway I am trying to figure out how this affects 
> things in compounded situations.

  If a #macro is located in another file, calling it is slower than if it's
located in the same file as the calling code. That's because each time the
macro is called that other file is opened, seeked, parsed and closed.
If the macro gets called a lot in a tight loop, the speed impact can be
noticeable.

> For instance what if I have a macro in an #included file but it is only 
> called once.  But IT calls a second macro multiple times.  Where is it 
> best to have the second macro reside?  Is there any advantage to having 
> it in the primary file or is it inefficient, no matter what, since it is 
> called from the #include file?

  I actually don't remember if POV-Ray knows not to re-open the file it's
currently parsing if it happens to be a different file than the main .pov
file.
  Try testing the actual speed differences.

-- 
                                                          - Warp

Post a reply to this message

I've been working with the assumption that an occasional call to an 
#included macro containing tight loop calling a second macro in the same 
#include file many times should be fairly efficient, based I think on 
posted tests from back-when and what Warp said again just now.
Charles

Post a reply to this message

Charles C wrote:
> I've been working with the assumption that an occasional call to an 
> #included macro containing tight loop calling a second macro in the same 
> #include file many times should be fairly efficient, based I think on 
> posted tests from back-when and what Warp said again just now.
> Charles
Yeah, that would seem right, but that is the solution I didn't want to 
use only because it would result in redundant copies of a macro that I 
wrote precisely to isolate reusable code.  Oh well, it is really more 
about design aesthetics than parse time anyway.

I wonder if it would make a difference if the whole thing was wrapped in 
a macro.  I'll try some tests.

Post a reply to this message

Jim Charter wrote:
> Charles C wrote:
>> I've been working with the assumption that an occasional call to an 
>> #included macro containing tight loop calling a second macro in the 
>> same #include file many times should be fairly efficient, based I 
>> think on posted tests from back-when and what Warp said again just now.
>> Charles
> Yeah, that would seem right, but that is the solution I didn't want to 
> use only because it would result in redundant copies of a macro that I 
> wrote precisely to isolate reusable code.  Oh well, it is really more 
> about design aesthetics than parse time anyway.
> 
> I wonder if it would make a difference if the whole thing was wrapped in 
> a macro.  I'll try some tests.

My parametric surface builder uses a macro in an included file to define the 
shape.  The #include code is in the parametric macro itself (called once), but 
the included macro is called thousands of times on occasion (once per vertex). 
I have noticed some lag if the grid is 100x100 or more.

What inefficiencies are involved with this type of process?

-- 
--------------
David Wallace
TenArbor Consulting
"Just In Time Cash"
www.tenarbor.com
1-866-572-CASH

Post a reply to this message

David Wallace nous apporta ses lumieres en ce 2008/03/24 16:24:
> Jim Charter wrote:
>> Charles C wrote:
>>> I've been working with the assumption that an occasional call to an 
>>> #included macro containing tight loop calling a second macro in the 
>>> same #include file many times should be fairly efficient, based I 
>>> think on posted tests from back-when and what Warp said again just now.
>>> Charles
>> Yeah, that would seem right, but that is the solution I didn't want to 
>> use only because it would result in redundant copies of a macro that I 
>> wrote precisely to isolate reusable code.  Oh well, it is really more 
>> about design aesthetics than parse time anyway.
>>
>> I wonder if it would make a difference if the whole thing was wrapped 
>> in a macro.  I'll try some tests.
> 
> My parametric surface builder uses a macro in an included file to define 
> the shape.  The #include code is in the parametric macro itself (called 
> once), but the included macro is called thousands of times on occasion 
> (once per vertex). I have noticed some lag if the grid is 100x100 or more.
> 
> What inefficiencies are involved with this type of process?
> 
When you use a macro from an #include, that file is loaded every time the macro 
is parsed. Open the file, read from the file, close the file. This take time, 
even if the file is cached in memory.
It would be beter is you put that macro into your code, or at least, in the same 
file as the calling macro.
#Called_Macro[macro stuff]
#Calling_Macro[some macro stuff..Called_Macro(...)..more macro stuff}

-- 
Alain
-------------------------------------------------
   The other day I came home and a guy was jogging, naked. I asked "Why?"  He 
said "Because you came home early."
	Rodney Dangerfield

Post a reply to this message

Alain wrote:

> When you use a macro from an #include, that file is loaded every time 
> the macro is parsed. Open the file, read from the file, close the file. 
> This take time, even if the file is cached in memory.
> It would be beter is you put that macro into your code, or at least, in 
> the same file as the calling macro.
> #Called_Macro[macro stuff]
> #Calling_Macro[some macro stuff..Called_Macro(...)..more macro stuff}
> 

Yes, in my case I want to use the Colefax spline macros which are 
packaged as an include file.  The macros are called mega times to 
retrieve spline points and build a mesh.  If I cut and paste the macros 
into my include file which contains my macros which call them, I cut the 
parse time by a factor of four or five.  If I leave them in their own 
include file, the parse time is degraded no matter where I insert the 
#include statement.

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> If I cut and paste the macros 
> into my include file which contains my macros which call them

  That sounds like a bad idea.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Jim Charter <jrc### [at] msncom> wrote:
> 
>>If I cut and paste the macros 
>>into my include file which contains my macros which call them
> 
> 
>   That sounds like a bad idea.
> 
Well I'm certainly open to suggestions.

Post a reply to this message

Jim Charter <jrc### [at] msncom> wrote:
> Warp wrote:
> > Jim Charter <jrc### [at] msncom> wrote:
> > 
> >>If I cut and paste the macros 
> >>into my include file which contains my macros which call them
> > 
> > 
> >   That sounds like a bad idea.
> > 
> Well I'm certainly open to suggestions.

  Maybe you didn't get my reference. Let me rephrase:

Jim Charter <jrc### [at] msncom> wrote:
> If I cut and paste the macros

  That sounds like a bad idea.

  ;)

-- 
                                                          - Warp

Post a reply to this message