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