On 11/11/2003 3:19 PM, Paul Johnson wrote:
> On Sat, Oct 25, 2003 at 01:27:41PM +0200, Gabor Szabo wrote:
>> 
>> The HTML files generated by Devel::Cover are huge.
>> I think some work should be done to reduce this size.
> 
> Michael said he's working on this [...]

My silence on this topic is because I've been doing a lot of work on it, not
because I've been doing nothing. ;) Actually, I think the HTML stuff is
finished. I had planned on looking into the text report format before sending
off my changes to Paul, but it wouldn't hurt to summarize the changes here and
get a little feedback.

Cosmetically, everything should look almost identical. Behind the scenes I've
pretty much gutted and rewritten everything. Most significantly, it no longer
requires (uses) the Template Toolkit.

The default behavior of the module is now to strip blank lines, POD, and
anything after the __DATA__ or __END__ tokens. For those of you who want this
information, you can specify that via the spiffy new options:

    cover -report html -option=pod,data,unified

The 'pod' option includes POD (and blank lines) from the source code in the file
report.

The 'data' option includes text after the __DATA__ or __END__ tokens in the file
report. (Note: the current report always strips this.)

The 'unified' option is something new. It generates a "unified" report for each
file. The detailed data that normally appears in the auxilliary reports (branch,
condition, etc.) is placed in the file report, and the auxilliary reports are
not generated.

Here are some size metrics from a null coverage run on HTML::Template (which is
114 kB by itself):

    old format                             2192 kB
    new format (default)                    326 kB
    new format w/ -option=pod,data          391 kB
    new format w/ -option=unified           340 kB
    new format w/ -option=pod,data,unified  406 kB

I've made every effort to clean up the output; removing unneeded markup and
literally squeezing out every last character I can -- particularly from the many
rows in the table. The output is meant to be small, not human-readable. (i.e.
there's no pretty-print formatting.) The reports all validate with two exceptions:

1) Sometimes there are weird characters in the branch/condition coverage data
   that CGI::escapeHTML doesn't seem to sanitize.
2) When generating unified reports, there are tags that read
               <table width="100%">...</table>
   The W3C validator claims that the 'width' attribute isn't valid for the
   XHTML 1.0 Basic DTD, even though their own pages and other resources
   I've looked at all seem to say that it is. Any insight appreciated.

As an added bonus: report generation is now much faster, presumably because of
the greatly reduced size as opposed to the implementation.

The new (and old) reports look a little odd in IE because it doesn't draw
borders around empty table cells. I can fix that (by embedding a &nbsp;) but
that grows the report size by about 10%, and I've already made concessions for
IE because it doesn't honor 'whitespace: pre' CSS. I'm debating adding a
'screw_ie' option that leaves out the hacks. It would save *another* 50 kB from
the reports above. :) I will put in the empty cell hack if there's enough interest.

I'm interested in any comments, particularly about the defaults (e.g. a
preference for POD in by default and a 'nopod' option instead) or ideas for
changes to the report contents/structure.

-mjc

Reply via email to