Hi all, I've given the perl6 wiki 'november' (http://github.com/viklund/november/tree/master) a go out of curiosity, and being surprised at the run times (page 35 of http://viklund.pp.se/november.pdf) have done some profiling using valgrind.
For the test case all I've been using is running test_wiki.sh for the main wiki page under valgrind. (I remember chromatic getting some significant improvements in the past, but I can't see any quick wins unfortunately) I'm still interpreting the results, but here are some headlines: * It looks like garbage collection is taking a third of the run time (this is easily verifiable without valgrind by running with and without -G) * Most of the GCs are happening in run_thaw to overcome a problem with hashes (1938 of the 2024 calls). I tried disabling the forced check, but it segfaults indicating that the problem is still there. Fixing this GC bug would allow us to shave off most of the GC time * If we factor out the GC altogether, the next set of interesting routines seem to be the oo_find_vtable and hash routines * The low-level hash routine parrot_hash_get_bucket is called nearly 33 million times (accounting for 20% of the time, including its children which do comparisons) * There are 3 routines, object.pmc/get_attrib_index, object.pmc/Parrot_Object_find_method and oo.c/Parrot_oo_find_vtable_override which use 'exists' to determine whether a key exists before doing another lookup to retrieve it. This results in about 10.5 million of the 32 million calls, so if we avoid performing this near-identical hash lookup then that's another 7% speedup. (I can't currently see what the cleanest way of doing this would be though) Hope that's interesting. I'm not sure that I feel confident trying to fix either of these, although if someone can suggest a way to tweak the API to combine the hash exists/lookup then I could give that one a go. (I believe PMCNULL is a legitimate value that could be stored in the hash, so we can't just check for it) Cheers, Nick
