Heatfiler; a js profiler slash code coverage tool

[Peter van der Zee]

Hi all,

In case you missed it, I've released a new tool called Heatfiler. It's
a profiler and code coverage tool for JS (of course) in JS (of
course). It works completely on the client and has no dependencies
(server or otherwise).

I built it using ZeParser to do the rewriting. It is count-based (not
time based, though it could be when using the micro time spec) and
gives you a real-time updating heatmap. You can run the code in the
page of the heatmap or the two separate in tabs. You can also pretty
easily integrate the profiler in an existing project.

See http://heatfiler.qfox.nl for the demo,
http://github.com/qfox/Heatfiler for the source and docs,
http://qfox.nl/weblog/268 for the blog post (mainly explaining how I
approached the rewriting of source code to do the magic).

Feedback is welcome. Note that this is a two day effort. It's not my
cleanest code ever. And I don't intend (right now anyways) to improve
the tool, short of bug fixing.

If anyone can think of a syntax case that would fail in the rewrite
rules (not covered by ignored tests), please let me know (or just file
a ticket on github). I think I've covered my bases pretty well, but I
wouldn't be surprised if I let a case through :)

Hope you like it,

- peter

[Ariya Hidayat]

I think this is a very good tool and would be useful in many many
scenarios. Well done!

For a similar technique but using different approaches, there are e.g.
Coverage (see http://coveraje.github.com/results.html) and also Cover
(https://github.com/itay/node-cover), although the latter does not
have color-coded reporter yet.

What I'd like to see to happen is the converging of a standardized way
to inject instrumentation to the code. This is the heart of all
JavaScript-based coverage. Just like syntax tree (AST) format,
interoperability is easy if everybody follows (more or less) the same
strategy instead of N different and incompatible ways.

Having a pure instrumentation tool only is still very useful. In
particular, if there is a possibility to instrument specific part of
the code only. For example, some testing tool can run the instrumented
code as part of its testing procedure and for the performance reason
it might not start by instrumenting everything.

Claus, probably it's time to evangelize such a standardized format (at
minimum, towards reaching "de-facto") for code instrumentation?


Thank you!

Best regards,

--
Ariya Hidayat, http://ariya.ofilabs.com
http://twitter.com/ariyahidayat

[Steven Roussey]

I'm fascinated by the heatmap. If it supported source map generation, then something like the Web Indpector (or later Firefox and Firebug) could give a heatmap back on the original source. 

--
http://clausreinke.github.com/js-tools/resources.html - tool information
http://groups.google.com/group/js-tools - mailing list information

--
Sent from Gmail Mobile

[Anton Kovalyov]

Heatmap looks awesome. We (JSHint) use Coveraje as our code coverage tool and I'd love to see similar heatmap there.

Anton

[Mark Hahn]

Looks awesome.

FYI: On latest dev version of chrome I'm getting an unreadable mess for the result.

[Peter van der Zee]

On Tue, Aug 28, 2012 at 7:01 PM, Mark Hahn <ma...@hahnca.com> wrote:
> Looks awesome.
>
> FYI: On latest dev version of chrome I'm getting an unreadable mess for the
> result.

Can you tell what might be going on? Maybe post a screenshot? I'm not
doing too much weird stuff, especially in the heatmap itself. It's
just a <pre> with some <span>s which have background colors. So I'm
not sure why that would screw up.

- peter

[Peter van der Zee]

I have updated Heatfiler to support nodejs and pretty much any
existing nodejs project.

See the github repo readme (http://github.com/qfox/Heatfiler) for
howto. It's just a simple require and calling a function.

It hooks into require.extensions and makes use of the undocumented
module._compile. I was ensured that this was the only way and that the
only alternative was to have people manually save converted source and
run it like that. This was actually "strongly encouraged". So F that.
I used _compile and I used it well.

Also fixed a silly bug where `(function(){}())` would cause an error
(because I was branching at `function` for either a function or an
expression start, but in this case it's both so code that was relying
on a span for the expression failed to find it).

Eh, have fun with it :)

- peter

[Claus Reinke]

> What I'd like to see to happen is the converging of a standardized way
> to inject instrumentation to the code. This is the heart of all
> JavaScript-based coverage. Just like syntax tree (AST) format,
> interoperability is easy if everybody follows (more or less) the same
> strategy instead of N different and incompatible ways.

> ..

> Claus, probably it's time to evangelize such a standardized format (at
> minimum, towards reaching "de-facto") for code instrumentation?

I'm always tempted by standard suggestions, in that they reduce
insecurity (which platform to invest work in) and encourage reuse:-)

However, given the experience with trying for standardized ASTs,
parsers, traversals, or transformations, I don't feel that is realistic
in Javascript. Those who invest their time seem to like having their
own solutions, even if it means that some problems have noone
working on them while others attract two or more coders.

Don't want to discourage you, though!-) Code instrumentation
is one of those areas where there is a common subset of tools
with a variety of useful applications.

Claus