global tags unnecessarily inflate concurrent test results

[Gary Poster]

This is, to be clear, a relatively mild annoyance, not a bug.

ThreadsafeForwardingResult handles global tags in _add_result_with_semaphore by wrapping each test with them: they are all set before the test results are rendered, and then all unset. This keeps the tags from polluting the tags in other concurrent tests.

If I understand the subunit tag semantics correctly, having local per-test tags would be semantically equivalent. This would also halve the number of times that global tags must be included in the stream. In the case of the LP parallel test stream, this would be a significant space savings, because layers are indicated with global tags, and we have many layers running at a time, and each layer tag name is long.

Working from the LP subunit parallel test output at http://dl.dropbox.com/u/420990/testrepo-0, a hack on the output showed that the reduced file would be 59% the size of the original (from http://pastebin.ubuntu.com/939060/ fwiw). For a 37M file, that's a decent amount of savings.

(Perhaps it could be a separate tags line, in case someone diagnosing the stream really wanted to know the source of the tag.)

[Robert Collins (lifeless)]

I think a clean way to address this would be a normalising filter after the multiplexing occurs, it can identify redundant tag operations and clean things up.
e.g.
==
tag: -foo bar
time: T
tag: -bar foo
time: T+n
==
->
==
==

[Gary Poster (gary)]

I talked with Robert about this and he is OK with my initial suggestion, which could work fine with his suggestion.

He pointed out that the general act of multiplexing streams breaks the subunit ability to cat two streams and have global tags from the first affect the second. That should be noted somewhere.

[Robert Collins (lifeless)]

Doing what Gary suggests would be find too.

[Robert Collins (lifeless)]

upgrading to critical given that this is tightly related to the misapplied-global-tags reported in testrepository.

[Robert Collins (lifeless)]

I'm going to Just Land a fix for this, as jml is busy/soon to be awol and the change is trivial. I'll take care of any post-landing followups that may be requested.