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
