[
https://issues.apache.org/jira/browse/GROOVY-12328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110514#comment-18110514
]
ASF GitHub Bot commented on GROOVY-12328:
-----------------------------------------
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.
> Improve JSON ReadCharacterSource performance
> --------------------------------------------
>
> Key: GROOVY-12328
> URL: https://issues.apache.org/jira/browse/GROOVY-12328
> Project: Groovy
> Issue Type: Improvement
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
