POV-Ray : Newsgroups : povray.beta-test : Optional way to handle #include files? : Re: Optional way to handle #include files? Server Time
30 Jun 2024 13:07:32 EDT (-0400)
  Re: Optional way to handle #include files?  
From: Le Forgeron
Date: 29 Jul 2010 17:52:28
Message: <4c51f81c$1@news.povray.org>
Le 29/07/2010 22:50, stbenge nous fit lire :
> Just thought I'd get some feedback before writing up a feature request.
> Right now, accessing functions and macros from an included file can be
> *slow*. It's not so bad when you're only accessing something once or
> twice, it's when you request something too many times.

> would be nice. What do you think? Would this kind of functionality be
> worth it?

In one word: no. (IMHO)

Your problem is not only the extras macro, but also the opening &
parsing the included files multiple time: IIRC macro are stored as file
& position in memory, when you invoke one, the file get (re-)opened, the
parser positionned at the right place, parsing occurs, on final #end the
file is closed.

So, for a distinct #include/macro, that means for each call:
 open()
 seek()
 ...
 close()
 continue original file

For an inline macro, only a:
 seek()
 ...
 continue original file

Now, what is the point of optimising the parser when the actual work of
rendering the picture might take hours, days or weeks ?
(And smart OS should be caching that file automatically anyway, but
open() can be slow)

If you really wants performance, a single file with a copy of the needed
macros (or even better, no macro call at all) is all you need.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.