.... try copying and pasting the most heavily used macros into the file they are
used in.

For instance, on my Windows XP machine the following code can be sped up to
parse *** 25 TIMES FASTER *** by un-commenting the second line:

#include "rand.inc"
//#macro VRand(RS) < rand(RS), rand(RS), rand(RS)> #end
#declare R = seed(42);
#declare i = 0;
#while (i < 100000)
  #declare V = VRand(R);
  #declare i = i + 1;
#end

On my Linux machine, it's not that extreme, but still a factor of 12.

Post a reply to this message

clipka <nomail@nomail> wrote:
> .... try copying and pasting the most heavily used macros into the file they are
> used in.

  This is actually a known phenomenon since the dawn of time. Of course
since it's not mentioned in any FAQ or documentation...

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> .... try copying and pasting the most heavily used macros into the file they are
> used in.

Yep, I'm using the same scheme in an animation that I'm running--it incorporates
numerous 'generic' macros that I made, which I *could* have saved as .inc files,
but instead are part of the SDL.  Iterated over 200 animation frames, that saves
LOTS of time. I've even done the same thing with several of the mesh-generation
macros in shapes.inc.

KW

Post a reply to this message

"clipka" <nomail@nomail> schreef in bericht 
news:web.49e6aeec231c37c2255d1edc0@news.povray.org...
> .... try copying and pasting the most heavily used macros into the file 
> they are
> used in.
>

Yes! and .inc content too of course, although less heavy generally speaking.
(Cannot be repeated enough)

Thomas

Post a reply to this message

clipka wrote:
> .... try copying and pasting the most heavily used macros into the file they are
> used in.
> 
> For instance, on my Windows XP machine the following code can be sped up to
> parse *** 25 TIMES FASTER *** by un-commenting the second line:
> 
> #include "rand.inc"
> //#macro VRand(RS) < rand(RS), rand(RS), rand(RS)> #end
> #declare R = seed(42);
> #declare i = 0;
> #while (i < 100000)
>   #declare V = VRand(R);
>   #declare i = i + 1;
> #end
> 
> On my Linux machine, it's not that extreme, but still a factor of 12.
> 
> 
> 
This is because each time a macro is called that is in a different file, 
the entire containing file is reopened, right? (I remember that from 
something in the documentation)

Thinking about that, I'd like to add 'storing macros in memory' for 
anything called more than once to the 4.0 SDL wishlist. Most other 
compliers do that as far as I know, but I do understand reasons behind 
the current behavior, since macros can be huge and all.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > .... try copying and pasting the most heavily used macros into the file they are
> > used in.
>
>   This is actually a known phenomenon since the dawn of time. Of course
> since it's not mentioned in any FAQ or documentation...

I don't know what is worse:  that it isn't mentioned or that humongous flat
scene files would be the norm was it mentioned in the docs. :P

Post a reply to this message

CShake <cshake+pov### [at] gmailcom> wrote:
> > For instance, on my Windows XP machine the following code can be sped up to
> > parse *** 25 TIMES FASTER *** by un-commenting the second line:
>
> This is because each time a macro is called that is in a different file,
> the entire containing file is reopened, right? (I remember that from
> something in the documentation)

Exactly.

> Thinking about that, I'd like to add 'storing macros in memory' for
> anything called more than once to the 4.0 SDL wishlist. Most other
> compliers do that as far as I know, but I do understand reasons behind
> the current behavior, since macros can be huge and all.

I would have taken for granted that if POV 4.0 SDL would operate on bytecode
basis, *all* macros of included files would reside in memory.

But I guess it would also be possible to first compile any files encountered
into bytecode files (unless the compiled files already exist and are
up-to-date), and then load macros from there, using some invocation counter to
decide whether to unload a macro again after use or keep it in memory.

Post a reply to this message