Rudy Velthuis wrote:
> 
> Ron Parker schrieb in Nachricht <36b8526e.0@news.povray.org>...
> >On Wed, 3 Feb 1999 14:10:20 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
> >>I have read somewhere, for #while loops, at the #end, the parser must
> >>re-read the source to find the #while, like old BASIC dialects did.
> >
> >Not true, fortunately.  It stores the offset within the file where the
> >#while appears and jumps directly to it upon hitting the #end.
> 
> Fortunately, yes.
> 
> >>Perhaps there would be demand for a small program, which unravels #while
> >>loops and macros and creates (huge) include files out of them, taking a
> bit
> >>out of the parsing POV-Ray does.
> >
> >Interesting idea, but I'm not sure you'll save much time, as that's
> >practically the same as what POV already does.  By seeking backward
> >in the file, it essentially duplicates the code as many times as
> >needed.  The only thing you'd save is a few seeks (nearly instantaneous
> >anyway except when it's a macro defined in another file), a few
> >expression evaluations (these could potentially be slow, but usually
> >aren't), and a few symbol lookups on your index variable (very fast.)
> 
> Still, the parser is an interpreter. Even if the allocation of objects takes
> much time, the interpreter also uses time, which Spider's example with the
> pre-computed trees proves. A pre-compiler (generating some kind of p-code,
> optimized for the language, perhaps) would be a nice feature IMHO. A good
> one could even look ahead and optimize (optimise) the allocations (yes I'm
> dreaming again).
now it isn't too much of a dream, searching for exact textures and
materials, grouping in a union and adding once is a pretty big memory
saving....
 
> I myself am used to a very fast compiler (Delphi)
yup, it's nice... Feels very good to have it.

>, so waiting for a parse is
> really annoying (first time I made a longer parse, I thought the program was
> hanging). You (MSVC) C++ guys are propably used to longer compile times <g>.
Hmm, not very much longer, some of the c compilers are astoundishing
fast.
 
> But I agree with the POV-team, that normally the render time is much more of
> a problem, so they should propably optimize (optimise) that first.
Yes, it is the most, but why keep a time hog(if small) when one can get
rid of it ?
yea yea, DIY I hear from someone... Well, I can't, that's why I'm here
and not doing it...



//Spider

Post a reply to this message