Alex Russell has a great post today on software performance, titled Performance Innumeracy & False Positives. Having worked in the embedded/mobile space for the last decade (on and off), I certainly feel his pain. On the other hand, this is one of the reasons why I love the mobile space: it's challenging.
Performance is just one of the challenges that we face in the mobile space. Other issues are program and data size, RAM usage, and network speed. All constrained compared to desktop-class machines.
For some of these challenges, we need tools, because it's often not obvious where the problems really are. Sometimes the only tools you have is your eyes staring at the code and intuition. Performance, in particular, is an area that needs tools. If there's one thing I've learned about performance problems over the years, it's this: your intuition is almost always wrong.
Alex showed a stack trace from WebKit in his blog post, without any kind of time numbers in it - a pretty crude tool. But most people don't even have that luxury (instrumenting WebKit), for applications running in a browser. On some mobile platforms, recompiling parts of the OS isn't even a possibility for most developers.
In lieu of actual tools, I'm always up for crazy hacks. That's basically what weinre is - a crazy hack. Take the Web Inspector user interface, and plug in a fake runtime behind it running on the target browser - just enough to get the user interface to display something interesting. Until we have the real Web Inspector showing us the browser innards running on a mobile platform, maybe this cheat will be useful to folks.
On a slightly related note, an interesting bug got entered against Web Inspector the other day: Bug 53659 - Web Inspector: Better support for finding "leaked" DOM. The summary describes a debugging scenario for which some new tooling could help. Here's the sad part: if this were Smalltalk, there's a chance you could write a specialized tool to collect the desired information with user-land code. The ability to enumerate all the live objects in a running image was an especially helpful feature. How useful would it be, if you could do that in JavaScript? In a special debugging mode, of course - not exactly a function you want to expose to everyone. But it would be nice to not have to wait for the platform developers to write tools for us, if we could write our own.
Could you help diagnose the scenario described in Bug 53659 with a crazy hack? If not, what's the bare minimum additional runtime functionality you'd need in JavaScript to do it?
