std.d.lexer requirements

Dmitry Olshansky dmitry.olsh at gmail.com
Thu Aug 2 13:20:58 PDT 2012


On 02-Aug-12 22:06, Walter Bright wrote:
> On 8/2/2012 4:47 AM, deadalnix wrote:
>> Le 02/08/2012 10:13, Walter Bright a écrit :
>>> As fast as the dmd one would be best.
>>>
>>
>> That'd be great but . . .
>>
>> lexer really isn't the performance bottleneck of dmd (or any compiler
>> of a non
>> trivial language). Additionally, anybody that have touched dmd source
>> code can
>> agree that usability/maintainability isn't as its best.
>>
>> Sacrificing some perfs in a non bottleneck area to increase ease of
>> use make
>> perfect sense.
>
> A lexer is like a device driver, or a memory allocator. Having it be as
> fast as possible pays off dividends endlessly for whoever uses it.
>

+1 Another point is that it's crystal clear *how* to optimize lexer, and 
gain some precious time. It is well trodden path with well known 
destination.
The time saved in lexer gives you some headroom in say optimizer, where 
you always can find more ways to improve result by sacrificing speed.

In the long run I totally expect millions of lines of D code in the wild.

> And in my profiling, lexing speed is a big factor in the debug build times.
>
> The Digital Mars C++ compiler (and its antecedents) made a lot of hay by
> being the fastest compiler available by a wide margin. A big advantage D
> has is also compile speed.
>
> Please do not underestimate its importance.


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list