Request for comments: std.d.lexer

[Dmitry Olshansky]

28-Feb-2013 13:09, Brian Schott пишет:
> On Saturday, 9 February 2013 at 07:55:04 UTC, Walter Bright wrote:
>> On 2/4/2013 7:19 PM, Brian Schott wrote:
>>> Still only half speed. I'm becoming more and more convinced that
>>> Walter is
>>> actually a wizard.
>>
>> I worship the Dark Arts.
>
> *recites incantations*
> *merges pull requests*
> *adds unit tests*
>
> http://hackerpilot.github.com/experimental/std_lexer/images/times4.png

Looking far better now. Keep in mind that we still don't use the 
original dmd's sentinel magic to avoid length check in std.d.lexer :)

Being that wizard who gave a couple of scrolls to Brain I'll outline 
some interesting data points collected while helping him out.

- D run-time takes some time to start up/shut down. It's on the order of 
1ms for me vs 1/10th of ms for plain C
- expanding on the previous point - GC.malloc takes sometime and 
triggers collections from time to time (2 collections to lex datetime, 
there is next to no garbage, but they run regardless).

Even simply disabling GC at first and re-enabling it at the end of 
program speeds up the whole time by roughly 5% on my machine.

- opApply is definitely slower then inlined range-based foreach loop 
even with scope delegate.

Other then this specifics the prime spells that give the performance are:

- don't use built-in AA or subtle allocations (avoid GC as far as you can)

- lean common path, keep there only the operations that are required in 
*every* code-path

- avoid ever doing the same work twice (redesign, hack and whatnot but 
don't do it)


-- 
Dmitry Olshansky