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

Warp wrote:
> 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.
> 
>   ;)
> 
The only other option I can think of is to call my include with its 
macros from within the Colefax include, probably slightly less subject 
to errors, but not much cleaner in any other regard.

Post a reply to this message

Jim Charter wrote:
> Warp wrote:
>> 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.
>>
>>   ;)
>>
> The only other option I can think of is to call my include with its 
> macros from within the Colefax include, probably slightly less subject 
> to errors, but not much cleaner in any other regard.

You still didn't get it. Warp doesn't like "cut & paste", he thinks it 
should be "copy & paste"...



-- Arttu Voutilainen

Post a reply to this message

Arttu Voutilainen <bli### [at] removethiszbxtnetinvalid> wrote:
> You still didn't get it. Warp doesn't like "cut & paste", he thinks it 
> should be "copy & paste"...

  No, "cut & paste" is ok, *if you are realling cutting*, not copying.
That is, you press ctrl-x. or whatever the shortcut is for "cut".

  However, more often than not, doing that is a bad idea.

-- 
                                                          - Warp

Post a reply to this message