paulk-asert opened a new pull request, #2855: URL: https://github.com/apache/groovy/pull/2855
…arge-file parser CharacterSource.findNextChar collects a string value one buffer at a time and joined the pieces with Chr.add, which allocates a fresh array and re-copies everything gathered so far on every refill. Reading a value of n characters through a 10,000-character buffer therefore cost O(n^2) in both copying and allocation churn. JsonSlurper.parse(File) routes files of 2MB or more to this parser, so the variant chosen for the largest inputs was the one that degraded worst on them. A value that fits inside a single buffer is still taken in one copy. Only a value that spans a refill builds a CharBuf and appends each further chunk to it, which keeps the total linear. Reading a 64MB string drops from 11528ms to 74ms, and doubling the input now doubles the time rather than quadrupling it. The existing findNextChar tests sweep every buffer size from 1 up, so they already cover the chunk boundaries; the added tests cover values far longer than the buffer, escapes landing on a refill boundary, and the unterminated-value error path, all of which now run through the accumulator. Note this is a performance fix: the tests pin the behaviour of the rewritten accumulation, not the complexity, which was measured. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
