In Python, appending strings is not guaranteed to be constant-time,since they are documented to be immutable.  In some corner cases,CPython is able to make these operations constant-time, but reachinginto ETree objects is not such a case.This leads to parse times being quadratic in the size of the text inthe input in pathological cases where parsing outputs a large numberof adjacent text nodes which must be combined (e.g. HTML-escapedvalues).  Specifically, we expect doubling the size of the input toresult in approximately doubling the time to parse; instead, weobserve quadratic behavior:```In [1]: import html5libIn [2]: %timeit -n1 -r5 html5lib.parse("<" * 200000)2.99 s ± 269 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)In [3]: %timeit -n1 -r5 html5lib.parse("<" * 400000)6.7 s ± 242 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)In [4]: %timeit -n1 -r5 html5lib.parse("<" * 800000)19.5 s ± 1.48 s per loop (mean ± std. dev. of 5 runs, 1 loop each)```Switch from appending to the internal `str`, to appending text to anarray of text chunks, as appends can be done in constant time.  Using`bytearray` is a similar solution, but benchmarks slightly worsebecause the strings must be encoded before being appended.This improves parsing of text documents noticeably:```In [1]: import html5libIn [2]: %timeit -n1 -r5 html5lib.parse("<" * 200000)2.3 s ± 373 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)In [3]: %timeit -n1 -r5 html5lib.parse("<" * 400000)3.85 s ± 29.7 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)In [4]: %timeit -n1 -r5 html5lib.parse("<" * 800000)8.04 s ± 317 ms per loop (mean ± std. dev. of 5 runs, 1 loop each)```