Am 18.05.2018 um 22:28 schrieb Kenneth:

> For sheer parse-time efficiency, I'm wondering if the number of separate code
> lines in a scene also makes a difference. In other words, is this more
> efficient...
> 
> #declare S=32+64+17;
> 
> ..... than this:
> 
> #declare S=
> 32
> +
> 64
> +
> 17
> ;
> 
> Does the scanner have to 'scan' the ENTER key's entry, when starting new
> lines like this?

Absolutely. It even makes a difference whether you're using a Windows or
Unix machine.

I would guesstimate that the multi-line version may be about as
performant as

    #declare S=   32   +   64   +   17   ;

when using Windows-style line endings, or

    #declare S=  32  +  64  +  17  ;

when using Unix-style line endings.


In ASCII text files, the length of each line is identified by a special
character (or character sequence) inserted into the character stream at
the end of each line.

On Windows, that end-of-line marker is customarily the (non-printable)
character sequence CR+LF (hex 0D 0A, Carriage Return followed by Line
Feed). On Unix it is customarily just the LF character (hex 0A).

If it weren't for error reporting, line endings would parse exactly as
fast as an equivalent number of other whitespace characters (two blanks
on Windows or one blank on Unix).

However, line endings also require some different handling to keep track
of location information for errors or warnings (although the difference
is minor): While normal characters increment the column, a line ending
increments the line number instead, and additionally resets the column.
In this context, some extra work is also required to handle the
multitude of possible line ending sequences: If it was just for CR+LF
(Windows) vs. LF (Unix), the end-of-line code could be triggered just on
LF while treating CR as a generic whitespace character; however, there's
also plain CR (classic Mac OS) that needs to be handled, and even LF+CR
(though that one's rather obscure).

My guesstimate is hat this extra processing amounts to about the same
workload as parsing an extra whitespace character, hence the above
guesstimates.

Post a reply to this message