Can't libc Do It?
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/ld-2.5.so] 2,985,581 mmd.c:mmd_expand_y [/home/chromatic/dev/parrot/blib/lib/libparrot.so.0.4.12] 2,974,773 ???:do_lookup_x [/lib/ld-2.5.so] 2,652,803 ???:_dl_relocate_object [/lib/ld-2.5.so]
Here's what happened when I dug into the code.
|Your this article is very good|
|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?|
@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.
|@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.|