Am 11.10.2017 um 13:59 schrieb Bald Eagle:

> I wasn't limiting my inquiry to loops - the parsing phase just always seemed to
> be an unusually / unexpectedly slow thing.

In some cases the slow thing isn't even the parsing, but the loading of
texture images.

> Now, I understand that there are a lot of things that take place under the hood,
> with lots of moving parts, and take place in ways I don't understand.
> But it seems to me that the scene text is already "pre-processed" to a certain
> degree - since we have real-time context-sensitive color coding.

That's just the editor, which is completely independent of the actual
parser/renderer pipeline.

> There's also plenty of time where the bulk of the text just sits there unedited
> while the user works on other parts of the scene or scrolls through re-reading
> it.   I realize that this text is likely unsaved, prone to editing, etc. and the
> editor is not the parser....

Running the parser whenever the user has made a change and is now idle,
is problematic for multiple reasons:

- The user could resume editing at any moment; in that case, parsing
would have to be aborted. (Likewise, the user may be editing other files
the scene needs, and the parser won't be able to detect that until it
runs into the corresponding `#include` statement.)

- The current architecture doesn't allow parsing of unsaved files; so
triggering the parser would only be possible once the user saves their
file. More often than not, I guess, this will be when the user pushes
the render button anyway.

- As you're surely well aware, running the parser constitutes quite an
effort (otherwise it wouldn't take that long). Triggering it whenever
the user has made a change and is now idle, would be quite a waste of
computing power (and hence energy). Also, parsing involves a lot of I/O,
which degrades overall performance and responsiveness of the system, and
can't be offset by multicore architectures.


> And that the parser necessarily (?) is limited to a single core, since the scene
> needs to be parsed in a linear manner.
> Perhaps something needs to be added to the language that makes multi-core
> parsing possible, if the SDL is written properly.

I wouldn't want to attempt that. The parser is fragile as it is, and I
wouldn't want to try making it multithreaded.

I'd rather "re-invent" the entire SDL and write a new parser based on
LLVM, using its intermediate format to allow for pre-parsing of include
files and utilizing its just-in-time capabilities for fast loop
execution and stuff (also, and maybe even more importantly, for
user-defined functions).

> Then there is the loop - which is how we got here in the first place.
> The loop gets parsed the first time - so perhaps there is a way for the [future]
> parser to process the loop content on that first pass

That approach is bound to fail at least for certain cases, as POV-Ray's
SDL allows to write self-modifying code (using `#write` and `#include`),
so each loop iteration may need re-parsing.

And again I wouldn't want to go through all the hassle of implementing
such a pre-parsing feature -- because it would essentially constitute a
partial re-write, and that energy would certainly be better invested
into a brand-new parser (with brand-new syntax).

Post a reply to this message