Optimization fun

[H. S. Teoh via Digitalmars-d]

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? (Or is there a post-processing step that
I'm missing?)

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.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.