* wrong data structure choices that compromised scalability
* very hot, very short and very simple subroutines that were rewritten in C using Inline::C
* targets for memoization, using the Memoize module
* excessive type checking
* small issues like checking existence in scalar instead of void context and minor algorithm improvements.

Last but not least, it put the last nail in the “Moose is slow” coffin, since never any Moose:: nor Class::MOP:: subroutine appeard at the top in the profiling reports. It was as if I had coded the thing in barebones OO Perl.

I’ve mailed you a more detailed explanation of this, as well as links to the most important diffs that made speed improvements. Hope it helps!

Other instances of use constant worked fine, but that constant invoked as a method on the class was mysteriously no longer callable when running under -d:NYTProf.

I’ll try to reproduce it stably later today.

As for the actual changes – most of them were applied to Class::MOP on August 14th 2008. They are pretty involved (code generation, order sensitive operation during the Class::MOP bootstrap. Basically it came down to lots of the meta objects not being immutable early enough or not having their bootstrap constructors overwritten, so constructing meta objects was slower than it needed to be).

Devel::NYTProf has two big advantages over all the other profilers as far as I’m concerned:

1. It seldom breaks. Many code bases break the other profilers, so an app big enough to need profiling is usually big enough to be unprofilable with other tools (though I have seen some strange things happen: http://github.com/nothingmuch/kiokudb/commit/0cc86555aebc8be8b17c26fc32af36dc07260e0b )

2. the output is very clear and very useful. by using a clean layout you can easily focus on the important data

Any chance you could email me some diffs?

You make a good point re ‘understanding the code flow’. I used it in that way when I started at a Shopzilla and found it invaluable for understanding the flow in the code base I was working on. I’ll add a note about that to the talk. Thanks.

Re inclusive times… The annotations injected into the source as comments show inclusive times. When looking at the report for a source file you can click on the columns of the subroutine summary table at the top to sort by inclusive time. Same goes for the ‘subroutine index’ page. Is that what you’re looking for? (It’s not obvious that they’re clickable.)

I used it recently to optimize one of our batch processes. With the clear and “actionable” information I had it going ~15-50% faster (depending on the dataset) within a few hours. Since it’s a process that can take days (or more!) to run, the speedup was significant.

One thing I wish it had was an easy way to see all the timestamps as “inclusive”. For my use at least I’m more often than not looking at those timestamps and right now I have to “hunt” for them manually (unless there’s an option I missed!).

– ask

Several months back I managed to get nytprof running on one of our development web servers at Craigslist to figure out why the code that renders our search result pages used so much CPU time. It just didn’t add up in my head.

After a few runs and some data analysis, I found that the CPAN module we used to help with time conversion (to display date/time in the user’s local time) was terribly inefficient and was getting called literally thousands of times per second. I found a better way to do this that used all built-in Perl features and it radically reduced the load on those boxes.

Ever since then I’ve been a big fan. nytprof presented that data in a way that made it *very* easy for me to understand the code flow in code I was still fairly new to at the time.

If memory serves, this shaved about 20ms (or 20%) off our typical response time in search, not to mention increasing overall capacity.