|
| Description: |
{{PlainTextStreamParser}} wraps each source it parses in a {{BufferedReader}}, which allocates a 16 KB buffer, even when the source is already in memory, like a {{StringReader}}. Allocating this buffer costs more than parsing a short text.
This matters for code that parses many short texts , like the :
* The code macro , which parses the text of each token of the highlighted code: highlighting a short snippet allocates several megabytes, which slows down the rendering of pages with many code macros, especially when many of them are rendered at the same time.
* Translation messages with parameters are formatted and parsed again each time they are rendered (translations without parameters are parsed once and then cached).
The buffer is only useful for a source that is costly to read character by character, so the parser shouldn't add one to a source that is already in memory or already buffered.
h2. Measurements
Parsing a translation message with parameters like {{MessageFormatTranslationMessage}} does (formatting a 60-character message, then parsing it into an XDOM), on an 8-core laptop, in two runs:
||Parser||Threads||Parses per second||Bytes allocated per parse||
|before|1|286,000 - 296,000|21,400|
|without the buffer|1|515,000 - 577,000|5,000|
|before|8|449,000 - 481,000|21,400|
|without the buffer|8|1,775,000 - 1,988,000|5,000|
Without the buffer, the parsing is about 1.9 times faster on 1 thread and 4 times faster on 8 threads: the allocation of the buffer was more than three quarters of the memory allocated per parse, and limited how the parsing scales on several threads (1.6 times faster on 8 threads than on 1 before, 3.4 times faster now).
For the code macro, see the measurements on XWIKI-25413.
|
|
