Pilihan binari pulangan tetap18 comments
Trading free bonus uk
So I decided to do a benchmark. I think, this is the principal methods to copy a file to another file. The different methods are available at the end of the post. Pay attention that the methods with Readers only works with text files because Readers are using character by character reading so it doesn't work on a binary file like an image.
Here I used a buffer size of bytes. Of course, use a higher value improve the performances of custom buffer strategies. And I made the tests first using text files and then using binary files. I made the tests using in three modes:. I used a benchmark framework, described here , to make the tests of all the methods. The tests have been made on my personal computer Ubuntu The Java version used is a Java 7 64 bits Virtual Machine.
We can see that here the native and naive streams methods are a lot slower than the other methods. The first conclusion we can do is that the naive readers is a lot faster than the naive streams.
It's because Reader use a buffer internally and this is not the case in streams. The others methods are closer, so we'll see with the next sizes what happens. The readers methods are slower than the equivalent streams methods because readers are working on chars, so they must make characters conversion for every char of the file, so this is a cost to add.
Another observation is that the custom buffer strategy is faster than the buffering of the streams and than using custom buffer with a buffered stream or a single stream doesn't change anything. The same observation can be made using the custom buffer using readers, it's the same with buffered readers or not. So the buffer of the streams or the readers is not useful here. Here we see the limits of the simple buffered stream and readers methods.
And another really interesting thing we see is that the native is now faster than buffered streams and readers. Native method must start an external program and this has a cost not negligible. But the copy using the cp executable is really fast and that's because when the file size grows, the native method becomes interesting.
All the other methods except the readers are almost equivalent. This time we can see that the native copy method is here as fast as the custom buffer streams. The fast method is the NIO Transfer method. We see exactly the same results as with a text file. The native method start to be interesting. We see precisely that the NIOand Path methods are really interesting here. Just to be sure of these results, let's test with a bigger file:.
Here we can see that the native method become to be the fastest one. The other method are really close. I thought the NIO Transfer will be normally faster.
Due to the size of the file the benchmark has been made only a little number of times, so the number can be inaccurate. We see that he Path method is really close to the other. The detailed informations standard deviation, confidence intervals and other stats stuff are available in the conclusion page. We see exactly the same results as in the first benchmark. The naive streams iscompletely useless for little files.
So let's remove itand see what happens for interesting methods:. Here again, the conclusion are the same and the times are not enough big to make global conclusions. Here, we have the limits of the buffered strategy and see a real advantage of custom buffer strategy. But again, the times are really short. So we covered the text files.
If we compare the times between the first benchmark the same disk and this method between two disk , we can see that the times are almost the same, just a little slower for some methods. So let's watch the big binary files:. This time, the differences are impressive. The native and NIO Buffer methods are the fastest methods. This transfer is a lot faster than on the same disk. I'm not sure of the cause of these results. The only reason I can found is that the operating system can made the two things at the same time, reading on the first disk and writing on the second disk.
If someone has a better conclusion, don't hesitate to comment the post. Here are the results of the first version of this post. The first disk is always the same, but the second disk is a NTFS.
For concision, I removed some graphes. I've also removed the conclusion that are the same as the first two benchmarks. The native method is not covered in these results. The best two versions are the Buffered Streams and Buffered Readers.
Here this is because the buffered streams and readers can write the file in only one operation. Here the times are in microseconds, so there is really little differences between the methods.
So the results are not really relevant. We can see that the versions with the Readers are a little slower than the version with the streams. This is because Readers works on character and for every read operation, a char conversion must be made, and the same conversion must be made on the other side.
The NIO buffer strategy is almost equivalent to custom buffer. And the direct transfer using NIO is here slower than the custom buffer methods. I think this is because here the cost of invoking native methods in the operating system level is higher than simply the cost of making the file copy. Here, it's now clear that the custom buffer strategy is a better than the simple buffered streams or readers and that using custom buffer and buffered streams is really useful for bigger files.
You can see that it doesn't take ms to copy a 50 MB file using the custom buffer strategy and that it even doesn't take ms with the NIO Transfer method. Really quick isn't it? We can see that for a big file, the NIO Transfer start to show an advantage, we'll better see that in the binary file benchmarks.
We will directly start with a big file 5 MB for this benchmark:. So we can make the same conclusion as for the text files, of course, the buffered streams methods is not fast. The other methods are really close. We see that all the methods are really close, but the NIO Transfer method has an advantage of ms. I think it's logical because the operating system must made conversions. But the custom buffer strategy and the NIO Buffer too are also really fast methods to copy files.
So perhaps, the best method is a method that make a custom buffer strategy on the little files and a NIO Transfer on the big ones and perhaps use the native executable on the really bigger ones.
But it will be interesting to also make the tests on an other computer and operating system. Here are the sources of the benchmark: File Copy Benchmark Version 3. Here are the informations complete for the benchmark between two disks: Complete results of first two benchmarks. Toggle navigation Blog blog "Baptiste Wicht" ;. So I searched all the methods to copy a File in Java, even the bad methods and found 5 methods: Make the copy using the cp executable of Linux Naive Streams Copy: Open two streams, one to read, one to write and transfer the content byte by byte.
Open two readers, one to read, one to write and transfer the content character by character. Same as the first but using buffered streams instead of simple streams. Same as the second but using buffered readers instead of simple readers.
Custom Buffer Stream Copy: Same as the first but reading the file not byte by byte but using a simple byte array as buffer. Custom Buffer Reader Copy: Same as the fifth but using a Reader instead of a stream.
Custom Buffer Buffered Stream Copy: Same as the fifth but using buffered streams. Custom Buffer Buffered Reader Copy: Same as the sixth but using buffered readers. Using NIO Channel and direct transfer from one channel to other. Path Java 7 Copy: Using the Path class of Java 7 and its method copyTo I think, this is the principal methods to copy a file to another file.