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