anton-vinogradov commented on code in PR #13319:
URL: https://github.com/apache/ignite/pull/13319#discussion_r3579881770
##########
modules/zookeeper/src/main/java/org/apache/ignite/spi/discovery/zk/internal/ZookeeperDiscoveryImpl.java:
##########
@@ -4064,33 +4066,20 @@ private <T> T unmarshalZip(byte[] zipBytes) throws
Exception {
/**
* @param obj Object.
- * @return Bytes.
+ * @return Zip-compressed marshalled bytes.
* @throws IgniteCheckedException If failed.
*/
byte[] marshalZip(Object obj) throws IgniteCheckedException {
assert obj != null;
- return zip(U.marshal(marsh, obj));
- }
-
- /**
- * @param bytes Bytes to compress.
- * @return Zip-compressed bytes.
- */
- private static byte[] zip(byte[] bytes) {
- Deflater deflater = new Deflater();
-
- deflater.setInput(bytes);
- deflater.finish();
+ GridByteArrayOutputStream out = new GridByteArrayOutputStream();
Review Comment:
Fair — agreed, pre-sizing is about cutting the resize garbage/copies, and
that's worth doing for the large join-data case. One clarification on the ratio
idea: we deliberately don't compute the uncompressed size anymore, so there's
no input length to take 1/3 of — obtaining it would mean re-materializing the
uncompressed `byte[]`, which is exactly the allocation this change removes. So
I can't scale the seed to the input without giving the peak-memory win back.
Instead I seed the output buffer with a fixed 8 KB initial capacity (same size
as the BufferedOutputStream we already allocate, so no new cost tier for small
messages), which drops the 32→…→N doubling cascade. Happy to bump the constant
if you'd like it more aggressive for the megabyte case — I just can't make it
proportional to the now-unknown input size.
--
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]
