This is not done by the parser but by the scanner. In theory, it should be faster, however, I doubt that a time difference is measurable in real world code, the rest of the compiler needs much more time.

Anybody actually done a speed test on this to see the speed difference?

In 1.0.x the scanner took a significant amount of time due to the much faster backend. I don't think it will matter with 2.x

Hi,

If the source code only contains tabs characters, instead of spaces, does... that means the source code files are a lot smaller. Does that also result in the compiler parsing those files faster? After all, there is a lot less characters to parse.

Anybody actually done a speed test on this to see the speed difference?

Regards,
- Graeme -

Skipping tab chars or the equivalent amount of space chars is not much different in runtime. More critical is the update of the current column, that is a simple inc(col,1) for spaces, but deserves some lengthier computation for tabs - in detail with elastic or otherwise variable tab stops. I'm not sure how the scanner can ever provide reasonable column values at all, when it's up to "the" (which???) editor, and the possibly user-specified tab width (Lazarus), to expand the tabs into spaces.

DoDi