clintropolis commented on code in PR #16698:
URL: https://github.com/apache/druid/pull/16698#discussion_r1669818388
##########
processing/src/main/java/org/apache/druid/segment/writeout/FileWriteOutBytes.java:
##########
@@ -33,22 +33,25 @@
import java.nio.channels.FileChannel;
import java.nio.channels.WritableByteChannel;
-final class FileWriteOutBytes extends WriteOutBytes
+public final class FileWriteOutBytes extends WriteOutBytes
{
private final File file;
private final FileChannel ch;
private long writeOutBytes;
- /** Purposely big-endian, for {@link #writeInt(int)} implementation */
- private final ByteBuffer buffer = ByteBuffer.allocate(4096); // 4K page
sized buffer
+ /**
+ * Purposely big-endian, for {@link #writeInt(int)} implementation.
+ * Direct because there is a material difference in performance when writing
direct buffers
+ */
+ private final ByteBuffer buffer = ByteBuffer.allocateDirect(32768); // 32K
page sized buffer
Review Comment:
i guess what i'm worried about is like the nested column serializer, which
makes child writeout mediums for the nested columns and closes them after the
nested column is finished to prevent an explosion of temp files. I'm hoping
there wont be an explosion of direct buffers that are dependent on GC to clean
up.. it might be cool, but also might not be?
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
