clintropolis commented on code in PR #16698:
URL: https://github.com/apache/druid/pull/16698#discussion_r1669804141
##########
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:
maybe leak is a bit strong of a word to use here, but nearly all the things
that use direct buffers explicitly invoke the cleaner when done with them
because it makes things more predictable imo, unless this is just superstition?
This thing is associated with a writeout medium which is explicitly closed,
perhaps we should allow pushing a closer in so the free can be tied to it?
--
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]
