"nemesis" <nam### [at] gmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   This is because, if the #macro is indeed in an included file, POV-Ray will
> > open that file, seek to the macro, parse it and close the file, and this each
> > time the macro is called. Thus the overhead is about as bad as an explicit
> > #include call.
>
> oh, man! This is freakish bad!  It really read the include file each time
> the macro is called?!  Is it an easy way to get local scoping for the macro
> by using the stabilished local file for the include files?... that hurts...


This is also part of the reason why I'm not as big of a fan of giving each
macro it's own file.  Most of my macros actually call on other macros and
if there's a #while loop in there, it's nice to already have it there in
the same file.  Of course I haven't done any tests like (was it Warp?)
somebody did a few months ago to see how much time I'm saving.

Charles

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:

> There *are* situations when using a macro is not the best solution. I
> regularly have include files which depend on a *lot* (i.e. 50+)
> parameters - you don't want to pass all these everytime you call a
> macro.


Me too, although there'll be macros in there too likely.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:

> I'll be downloading the source-code tonight to see things for myself and
> perhaps implement a demo for my #includeas proposal...

Nice :)

I think some friendly competition would be beneficial to the whole POV-Ray
project.  I have a feeling that we - the community - are on our way to
discovering some amazing new implementations in the SDL, whatever it ends
up looking like.  If my "retroactive aliasing" model ends up being nothing
more than a pipe dream, then so be it.

I'm looking forward to seeing what you come up with.

-Randall

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I'm looking forward to seeing what you come up with.

i'll have to actually get down to C level because it was with much sadness
that i witnessed for the first time how limited file I/O is in the SDL:
#read don't work as expected, it's actually more akin to C's scanf.  This
is sad because i was trying to write a includeas macro which would scans
the included files line-by-line to search for #declares and rewrite them
with prefixes... no way to do it... so, C we go!

Post a reply to this message

BTW to nemesis and anyone else whose been following the the topic of
'aliasing':

I recently made reference to "cork" and "tungsten" (Includes - Standards
#53).  If you didn't already know I was referring to, here it is:

Legend has it that Thomas Edison already knew that the electric light bulb
was possible in principle before he actually made one that worked.  All he
needed was to find the right material for the element.  Instead of ruling
out any possibility, he decided to try every material he could think of -
even the ones he knew wouldn't work - including cork.  Eventually he
settled on tungsten - it worked the best.

Alchemically speaking:  Of all the metals in the periodic chart, tungsten
has the highest melting-point.  I feel that well-made software should be
like tungsten.  It should glow white-hot without burning out when you put a
high current through it.  I'll leave the gold to the user in posession of
the software that's made of tungsten.

-Randall

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Has it been decided that SDL will get a complete overhaul, then?  And 
> what about backwards compatibility - is POV-Ray finally giving up on it?

  As far as I know, nothing specific has been discussed yet. However, it has
been long been a simple fact that the current SDL is a bunch of kludges over
older kludges and it just doesn't scale. Adding more and more new features
to the current SDL just makes it worse, not better.

  A "new SDL" doesn't necessarily mean a new scripting language which will
look completely different from the current SDL, although I'm sure that
whatever will be developed, there will be some differences, but only for
the better.

  The user-defined functions in POV-Ray (which form their own syntax space,
separate from the SDL, and which are about 100 times more efficient than
#macros because they are byte-compiled) is a step towards the ultimate goal.

-- 
                                                          - Warp

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Alchemically speaking:  Of all the metals in the periodic chart, tungsten
> has the highest melting-point.  I feel that well-made software should be
> like tungsten.  It should glow white-hot without burning out when you put a
> high current through it.  I'll leave the gold to the user in posession of
> the software that's made of tungsten.

Povray is culture too. :)

Post a reply to this message

Warp wrote:
>   This is because, if the #macro is indeed in an included file, POV-Ray will
> open that file, seek to the macro, parse it and close the file, and this each
> time the macro is called. 

I knew this, but I never realized one of the implications before: If 
you're working on writing macro code, and you start a render, you may 
break the render by editing the file the macro is in before the render 
is done, yes?

(Of course, on decent operating systems, and even Windows, reading the 
same file a bunch of times in a row isn't all that much overhead, 
compared to reading it the first time.)

-- 
   Darren New / San Diego, CA, USA (PST)
     Scruffitarianism - Where T-shirt, jeans,
     and a three-day beard are "Sunday Best."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I knew this, but I never realized one of the implications before: If 
> you're working on writing macro code, and you start a render, you may 
> break the render by editing the file the macro is in before the render 
> is done, yes?

  Only during parsing.

> (Of course, on decent operating systems, and even Windows, reading the 
> same file a bunch of times in a row isn't all that much overhead, 
> compared to reading it the first time.)

  Even in decent OSes it is a lot of overhead compared to eg. having
the macro in memory. Or even in the same file.

  You can test this in practice: Make a loop which calls a macro which
is located in another file and measure how long it takes. Then move the
macro to the current file (where the loop is) and measure again. You will
probably get a significant increase in speed.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Only during parsing.

Oh yes. That makes sense. Most of my scenes parse pretty quickly, even 
the big ones.

-- 
   Darren New / San Diego, CA, USA (PST)
     Scruffitarianism - Where T-shirt, jeans,
     and a three-day beard are "Sunday Best."

Post a reply to this message