coverage html with show_contexts = True may produce a 196MiB file that can't be opened in a browser

[abo-abo]

Describe the bug
In case a file is covered by thousands of contexts, the HTML file produces is too big to be opened in Firefox - the browser simply hangs.

To Reproduce
Our codebase's .coverage is around 55MiB and looks like this:

sqlite> select count(*) from file;
1249
sqlite> select count(*) from context;
26184
sqlite> select count(*) from line_bits;
567073

Running coverage html with show_contexts = True takes a long while.

without show_contexts:

HTML size = 124MiB
gen time = 1m30s

with show_contexts:

HMTL size = 1.5GiB
gen time = 2m40s

The bulk of the size in generated HTML is occupied by:

<span class="ctxs">
  <span>python_fname::test_name|run</span>
  ...
</span>

Expected behavior / Proposed solution
Maybe some kind of ad-hoc compression could work?
Replace the span with:

<span class="ctxs">
  4,8,15,16,23,42
  ...
</span>

Then embed a JS block with a dictionary that maps the numbers above to python_fname::test_name|run. On expanding the ctxts span, JS could populate it with content.

I've estimated that at 120 chars per pytest context name and all 26184 contexts included into the JS block, the block will be around 3.14MiB. Which is a lot less than the 192MiB HTML file that Firefox can't open. And that's just for the largest file.
The size of the smaller files could improve. One 3.5MiB file that I looked at has a context repeating 45 times. Compressing it to tar.gz has reduced the size to 292K.

A simple alternative is to add an option to render only the first 10 contexts in HTML. Feels a bit bad to generate a lossy report though.

[nedbat]

Hi, I considered something like this when I first added contexts to the HTML report, though I didn't imagine 26k contexts!

I'm wondering if you really want to display all the contexts in the HTML report? It seems like it would be overwhelming. Maybe there's a way to reduce the number of contexts to something that would be more useful? Can be bunched together somehow?

[abo-abo]

I've had a look and have no idea how the contexts can be bunched up in a useful way. One line for example is annotated to be touched by 64 tests. Another by 424 tests. Yet another by 2 tests. It's potentially useful for the user to know all the test names that touch a particular line: we can then search by a keyword to examine closer an integration test in an area we're more interested in.

We're a team of 70 engineers working together on a large code base. I think it would be useful to be able to answer "Which tests cover this function?" quickly. I think coverage html is a useful step in this direction. We'd only need to handle the HTML file size.

[nedbat]

I'm wondering if there's a better way to solve your problem, like some kind of interactive context explorer. I just don't know how feasible it is to stuff that much information into a static HTML page, and you will have thousands of those pages.

[nedbat]

This is now released as part of coverage 7.2.3.