Ah, I wasn't clear. Yes, its very slow there with unencapsulated stdout, and nice and fast without. The file failed-subunit2 has unencapsulated stdout, and failed-subunit2.2 has encapsulated stdout.
unencapsulated: time PYTHONPATH=../../python ../../filters/subunit-ls --no-passthrough < ~/Downloads/failed-subunit2 | wc -l 6846
real 2m25.130s user 2m14.084s sys 0m11.006s
encapsulated: time PYTHONPATH=../../python ../../filters/subunit-ls --no-passthrough < ~/Downloads/failed-subunit2.2 | wc -l 6426
real 0m1.063s user 0m1.014s sys 0m0.049s
We should obviously fix this.
A workaround would be to generate encapsulated stdout from the get-go. How was the stream generated?
Ah, I wasn't clear. Yes, its very slow there with unencapsulated stdout, and nice and fast without. The file failed-subunit2 has unencapsulated stdout, and failed-subunit2.2 has encapsulated stdout.
unencapsulated: ../../python ../../filters/ subunit- ls --no-passthrough < ~/Downloads/ failed- subunit2 | wc -l
time PYTHONPATH=
6846
real 2m25.130s
user 2m14.084s
sys 0m11.006s
encapsulated: ../../python ../../filters/ subunit- ls --no-passthrough < ~/Downloads/ failed- subunit2. 2 | wc -l
time PYTHONPATH=
6426
real 0m1.063s
user 0m1.014s
sys 0m0.049s
We should obviously fix this.
A workaround would be to generate encapsulated stdout from the get-go. How was the stream generated?