On Wed, 25 Aug 2010 15:11:17 -0400, retard <r...@tard.com.invalid> wrote:
Wed, 25 Aug 2010 19:08:37 +0000, dsimcha wrote:
== Quote from retard (r...@tard.com.invalid)'s article
Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:
> On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright
> <newshou...@digitalmars.com> wrote:
>
>> Steven Schveighoffer wrote:
>>>> Just goes to show how useful a profiler is.
>>> Yes, I'm glad you pushed me to do it. Looking forward to the fix.
>>
>> The two secrets to writing fast code are:
>>
>> 1. using a profiler
>> 2. looking at the assembler output of the compiler
>>
>> In my experience, programmers will go to astonishing lengths to
>> avoid doing those two...
>
> You mean like asking someone who reported low performance of your
> program on the newsgroup to do it for you? :)
He forgot:
0. use a better algorithm (the big O notation matters, like in this
case)
Yeah, but unless you use a profiler, how are you going to find those
spots where N isn't as small as you thought it would be?
Test-driven develoment, automatic testing tools, common sense? Sometimes
the profiler's output is too fine-grained.
On the contrary, this was one of those bugs that you almost need a
profiler for. Consider that after over 10 years of d compilers nobody has
found this deficiency until my little library came along. And even then,
it's hard to say there actually *is* a problem, the compiler runs and
outputs valid code, and if you use the -v switch it's continuously doing
things. Even when you profile it, you can see that the errant function
only consumes small chunks of time, but it adds up to an unacceptable
level.
Test-driven development is only useful if you have a certain criteria you
expect to achieve. How do you define how fast the compiler *should* run
until you run it? It's a very complex piece of software where performance
is secondary to correctness.
I can understand not having touched code that outputs an object format for
20 years. I don't regularly go through my code looking for opportunities
to increase big-O performance.
I'm just glad it's been found and will be fixed.
-Steve
