StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I don't think you will be able to get a strict answer without benchmarking your software. NIO may speed up the application significantly under the right conditions, but it may also make things slower. Here are some points:</p> <ul> <li>Do you really need strings? If you store and receive bytes from you database you can avoid string allocation and encoding costs all together.</li> <li>Do you really need <code>rewind</code> and <code>flip</code>? Seems like you are creating a new buffer for every string and just writing it to the channel. (If you go the NIO way, benchmark strategies that reuse the buffers instead of wrapping / discarding, I think they will do better).</li> <li>Keep in mind that <code>wrap</code> and <a href="http://download.oracle.com/javase/6/docs/api/java/nio/ByteBuffer.html#allocateDirect%28int%29">allocateDirect</a> may produce quite different buffers. Benchmark both to grasp the trade-offs. With direct allocation, be sure to reuse the same buffer in order to achieve the best performance.</li> <li>And the most important thing is: Be sure to compare NIO with <a href="http://download.oracle.com/javase/6/docs/api/java/io/BufferedOutputStream.html">BufferedOutputStream</a> and/or <a href="http://download.oracle.com/javase/6/docs/api/java/io/BufferedWriter.html">BufferedWritter</a> approaches (use a intermediate <code>byte[]</code> or <code>char[]</code> buffer with a reasonable size as well). I've seen <a href="http://www.coderanch.com/t/279166/Streams/java/Writing-String-File-FileChannel">many</a>, <a href="http://www.thebuzzmedia.com/java-io-faster-than-nio-old-is-new-again/">many</a>, <a href="http://technicalmumbojumbo.wordpress.com/2011/03/17/file-io-old-io-or-nio-which-is-better/">many</a> people discovering that NIO is no silver bullet. </li> </ul> <p>If you fancy some bleeding edge... Back to <a href="http://download.oracle.com/javase/tutorial/essential/io/file.html">IO Trails</a> for some NIO2 :D.</p> <p>And here is a <a href="http://www.baptiste-wicht.com/2010/08/file-copy-in-java-benchmark/">interesting benchmark about file copying using different strategies</a>. I know it is a different problem, but I think most of the facts and author conclusions also apply to your problem. </p> <p>Cheers,</p> <p><strong>UPDATE:</strong></p> <p>Since @EJP tiped me that direct buffers wouldn't be efficient for this problem, I benchmark it myself and ended up with a nice NIO solution using nemory-mapped files. In my Macbook running OS X Lion this beats <code>BufferedOutputStream</code> by a solid margin. but keep in mind that this might be OS / Hardware / VM specific:</p> <pre><code>public void writeToFileNIOWay2(File file) throws IOException { final int numberOfIterations = 1000000; final String messageToWrite = "This is a test üüüüüüööööö"; final byte[] messageBytes = messageToWrite. getBytes(Charset.forName("ISO-8859-1")); final long appendSize = numberOfIterations * messageBytes.length; final RandomAccessFile raf = new RandomAccessFile(file, "rw"); raf.seek(raf.length()); final FileChannel fc = raf.getChannel(); final MappedByteBuffer mbf = fc.map(FileChannel.MapMode.READ_WRITE, fc. position(), appendSize); fc.close(); for (int i = 1; i < numberOfIterations; i++) { mbf.put(messageBytes); } } </code></pre> <p>I admit that I cheated a little by calculating the total size to append (around 26 MB) beforehand. This may not be possible for several real world scenarios. Still, you can always use a "big enough appending size for the operations and later truncate the file. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload