nishantmehta opened a new pull request, #439: URL: https://github.com/apache/commons-codec/pull/439
## Summary `BaseNCodec.encode(byte[], int, int)` — which backs `encode(byte[])`, `encodeToString` and the static `Base64`/`Base32` helpers — created a `Context` whose buffer was lazily allocated by `ensureBufferSize` at `max(size, 8192)`. For a one-shot encode of a small input this allocated the full **8192-byte default streaming buffer** regardless of the actual output size. The exact output size is already computable via `getEncodedLength`, so this pre-sizes the context buffer to it before encoding. The streaming path (`Base64OutputStream` etc.) is unchanged and still grows from the default size. When the encoded length does not fit an `int` the code falls back to the streaming buffer (such an output cannot be returned as a single array anyway). `getEncodedLength(byte[])` is refactored to delegate to a private length-based helper so the one-shot encode can size from the requested range length. ## Measurement ThreadMXBean allocation driver, 200k warmed ops, 25-byte input: | call | before | after | |------|--------|-------| | `Base64.encodeToString` | 8479 B/op | 345 B/op (−96%) | | `Base32.encodeToString` | 8592 B/op | 458 B/op (−95%) | ## Testing `Base64Test`, `Base32Test`, `Base16Test`, `BaseNCodecTest` and the Base64 input/output stream tests pass unchanged (360 tests). The streaming buffer growth path is exercised by the existing stream tests. -- 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]
