Steven Schveighoffer wrote:
> You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)

1. He had the test case, I didn't.

2. People have repeatedly suggested I delegate some of the compiler work. Why not?

retard wrote:
> He forgot:
> 
> 0. use a better algorithm (the big O notation matters, like in this case)

No, I didn't forget that. There's no benefit to using a better algorithm in the code that isn't the bottleneck. In my experience, even very experienced developers are nearly always wrong about where the bottlenecks are if they've never used a profiler.

retard wrote:
> Wed, 25 Aug 2010 19:08:37 +0000, dsimcha wrote:
>> 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,

Neither of those are designed to find bottlenecks, and I've never seen one that could. Besides, why avoid a tool that is *designed* to find bottlenecks, like a profiler?


> common sense?

Is not a substitute for measurement. Like I alluded to, I've seen lots of programmers using common sense to optimize the wrong part of the program, and failing to get useful results. Yes, I've had them *insist* to me (to the point of yelling) that that's were the bottlenecks were, until I ran the profiler on their code and showed them otherwise.


> Sometimes the profiler's output is too fine-grained.

There are many different profilers, with all kinds of different approaches. Some high level, some at the instruction level, some free, some for pay. All of them are cheaper than spending hundreds of hours optimizing the wrong part of the code.

bearophile wrote:
> And regarding the problem of searching in a sequence of items, if the
> sequence is small (probably up to 10 or 20 if the items are integers, the
> language is a low level one and the associative array is not very efficient),
> a linear search or a binary search is often faster.

Yup, and that piece of code was written in a time where there were very few items added into the string table. It never showed up on the radar before.

On Wed, 25 Aug 2010 16:29:06 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)
>
> 1. He had the test case, I didn't.

He == me :)

The test case was available as a tarball download at www.dsource.org/projects/dcollections.

Not that I mind doing the dirty work, if it gets results, but asking someone to compile your product in a different way and then asking them to try and analyze the output of *your* program isn't the best way to get results.  If I told Microsoft that Word was crashing on a document it made, and they responded by sending me the source code for Word and said "You have the test case, so you figure it out" I don't think people would like them very much.  I have had this problem for months, and haven't really pushed it except for snide remarks until recently, when I figured if I didn't do it, nobody would.

I understand the lack of time, and that was why I did the work, but I didn't really expect to get results.

> 2. People have repeatedly suggested I delegate some of the compiler work. Why not?

What I've done hardly qualifies as doing compiler work.  I just helped identify the problem :) I hope you plan on fixing it, I can't.

-Steve

== Quote from Walter Bright (newshound2@digitalmars.com)'s article
> bearophile wrote:
> > And regarding the problem of searching in a sequence of items, if the sequence is small (probably up to 10 or 20 if the items are integers, the language is a low level one and the associative array is not very efficient), a linear search or a binary search is often faster.
> Yup, and that piece of code was written in a time where there were very few items added into the string table. It never showed up on the radar before.

I wonder how much of the compile time of more typical projects is taken up by this linear search.  Could it be that that's also why std.stdio compiles relatively slow?  It's a big module that does a lot of template instantiations.  If this silly bug was a bottleneck everywhere, then I'd love to see D vs. Go compile times after this gets fixed.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:i53ucl$22nt$1@digitalmars.com...
>
> Right, assembler isn't hard to read after you spend a few moments with it. After all,
>
> MOV EAX,3
>
> is hardly rocket science!

Heh, funny thing about difficulty is how relative it can be. I've heard people who do rocketry say that rocket science really isn't as hard as people think. But programming doesn't come very naturally to most people, either. It would be funny to hear one rocket scientist say to another rocket scientist, "Oh come on, it's not computer programming!"

Nick Sabalausky wrote:
> "Walter Bright" <newshound2@digitalmars.com> wrote in message 
>> is hardly rocket science!
> Heh, funny thing about difficulty is how relative it can be. I've heard people who do rocketry say that rocket science really isn't as hard as people think. But programming doesn't come very naturally to most people, either. It would be funny to hear one rocket scientist say to another rocket scientist, "Oh come on, it's not computer programming!" 

Doing amateur rocketry isn't that hard, the formulas are simple and the more complex stuff (the engines) are off-the-shelf components. It isn't even that hard to build your own engines.

The harder stuff is when you put a man on the top of it, and you try to make it reliable.

dsimcha wrote:
> I wonder how much of the compile time of more typical projects is taken up by this
> linear search.  Could it be that that's also why std.stdio compiles relatively
> slow?  It's a big module that does a lot of template instantiations.  If this
> silly bug was a bottleneck everywhere, then I'd love to see D vs. Go compile times
> after this gets fixed.

It could very well be the source of these issues.

Steven Schveighoffer wrote:
> On Wed, 25 Aug 2010 16:29:06 -0400, Walter Bright <newshound2@digitalmars.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>> You mean like asking someone who reported low performance of your program on the newsgroup to do it for you? :)
>>
>> 1. He had the test case, I didn't.
> 
> He == me :)
> 
> The test case was available as a tarball download at www.dsource.org/projects/dcollections.
> 
> Not that I mind doing the dirty work, if it gets results, but asking someone to compile your product in a different way and then asking them to try and analyze the output of *your* program isn't the best way to get results.  If I told Microsoft that Word was crashing on a document it made, and they responded by sending me the source code for Word and said "You have the test case, so you figure it out" I don't think people would like them very much.  I have had this problem for months, and haven't really pushed it except for snide remarks until recently, when I figured if I didn't do it, nobody would.
> 
> I understand the lack of time, and that was why I did the work, but I didn't really expect to get results.

I hope that you enjoyed doing this, and I hope to make building the compiler an easy thing for users to do, if they are so inclined. I also wanted to push the issue of using a profiler <g>.


>> 2. People have repeatedly suggested I delegate some of the compiler work. Why not?
> 
> What I've done hardly qualifies as doing compiler work.  I just helped identify the problem :) I hope you plan on fixing it, I can't.

Yes, I'll fix it.