Optimization fun

[Walter Bright via Digitalmars-d]

On 11/7/2014 4:41 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Nov 07, 2014 at 04:22:49PM -0800, Walter Bright via Digitalmars-d wrote:
>> On 11/7/2014 2:58 PM, Dmitry Olshansky wrote:
>>> That's the problem with profilers:
>>>      they say what takes time but not why :)
>>>
>>> Often I find myself looking at memcpy at the top of the list, so
>>> obvious the "textbook" answer is to optimize memcpy ;) In contrast it
>>> should be read as "you seem to do excessive copying of data".
>>
>> dmd's profiler will give you a tree showing who called each function
>> how many times. This helps a lot with the "why" question.
>
> gprof also shows that in the section section of its output.
>
> But speaking of which, I found dmd -profile's output in trace.log a
> little difficult to understand because of the lack of self-documenting
> headers in the first section. gprof, for example, produces
> nicely-labelled output that describes what the data means. Would you
> accept a PR along these lines?

I don't really know what you have in mind, so I'll have to say "it depends". 
Keep in mind that subsequent runs of the profiler parse the previous output file 
and add it to the results.


> Also, in the second section, I'm getting some negative numbers for the
> call times, which seem to indicate integer overflow? This basically
> destroys the usefulness of dmd -profile for my test cases, since most of
> the interesting cases for me are those with long running times, which
> for sure will run into integer overflow at the sample rate that dmd
> -profile is using, causing the second section to be essentially randomly
> sorted.

Yeah, a negative number is likely an overflow. Reduce the test case!