Am 21.04.2018 um 18:38 schrieb Le_Forgeron:

> 2. I'm ready to help, I already have a debug version (with symbols in
> code) of povray and a profiling tool that does not slow down too much
> (not valgrind)

I'm pretty sure this isn't a matter of optimizing the hell out of any
particularly time-consuming function(s) participating in the parsing,
but rather of modifying the parser's fundamental way of operation.

For instance, POV-Ray's parser is comprised of:

(1) A /tokenizer/, which identifies the individual syntactic units in
the file (e.g. `#`, `define`, `MyVar`, `=`, `0.815`, `;`) and converts
each into an internal representation.

(2) An /interpreter/, which takes the stream of internal token
representations and interprets them.

Currently, the tokenizer is executed "on the fly", processing a single
token whenever the interpreter asks for the next one. This is true even
in loops, meaning that the loop body is re-tokenized all over again for
each iteration.

It would be faster to tokenize the entire file (or at least the loop
body) just once, keeping the internal representation in memory, and then
letting the interpreter loose on it.

This would also open up an opportunity for parallelization: One
dedicated tokenizer thread could go ahead processing the entire file,
while one dedicated interpreter thread could already start interpreting it.

But alas! Pulling the tokenizer and interpreter apart is not as easy as
it sounds, as POV-Ray's tokenizer currently goes one step too far: When
it comes to variable identifiers, its duty is not to just report
"potential variable identifier", but rather e.g. "unknown identifier" or
"variable holding a float" (*) -- which is impossible to decide outside
a particular interpreter context.

(* This is even true for array element access, e.g. `MyArray[I+1]` --
which even requires the tokenizer to recursively invoke the parser, to
evaluate `I+1` in this case.)

Post a reply to this message