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