Can't libc Do It?

by chromatic

I ran across a mention of Callgrind in a weblog the other day. "Hm," I thought. "I should use that to profile Parrot."

I have a little PIR program that prints "Hello, world!". I use it for valgrinding Parrot. Profiling Parrot's startup and shutdown time seemed useful:

$ valgrind --tool=callgrind -v parrot hi.pir

When you do this, run callgrind annnotate on the resulting output file to get a nice report of which functions did the most work. I saw:

20,301,112  PROGRAM TOTALS

3,034,654  ???:dl_new_hash [/lib/]
2,985,581  mmd.c:mmd_expand_y [/home/chromatic/dev/parrot/blib/lib/]
2,974,773  ???:do_lookup_x [/lib/]
2,652,803  ???:_dl_relocate_object [/lib/]

Here's what happened when I dug into the code.


2007-05-28 09:23:56
Your this article is very good
Ralph Corderoy
2007-06-05 03:46:12
Doesn't this confirm Perl's doom? lwall would never have written code like this. If Parrot's written to this standard it'll take a lot of work to being it up to Perl 5 performance, no?
2007-06-05 10:40:47
@Ralph, I'm not sure how to answer your questions. I do invite you to compare the code in almost any part of Parrot with the code in almost any part of Perl 5. One's under active development (and regular review of coding standards and clarity) and the other's in maintenance mode, where very few people want to disturb old code.

One also has had very little optimization and profiling work--because it's not yet finished.

Ralph Corderoy
2007-06-08 03:33:27
@chromatic: The old parrot code you've replaced had poorer clarity than the new, and faster, code. It is longer with more hoops to jump through to understand what it is attempting, and the reader is further confused by having to wonder what they're missing. They must be missing something, they think, else why wouldn't the author had written it the new way.