tag:blogger.com,1999:blog-5560209661389175529.post4208696484085669390..comments2021-11-26T19:34:10.855+00:00Comments on Mechanical Sympathy: Java Sequential IO PerformanceMartin Thompsonhttp://www.blogger.com/profile/15893849163924476586noreply@blogger.comBlogger30125tag:blogger.com,1999:blog-5560209661389175529.post-40667410020860407762020-10-28T10:24:26.781+00:002020-10-28T10:24:26.781+00:00I know it is an old topic. Nevertheless, I attach ...I know it is an old topic. Nevertheless, I attach my results, running on a virtualized Red Hat system (400MB size). I was interested in the varying block size effect. Perhaps somebody out can me clear up about the effect of the larger bloksize (better IO vs. more CPU time).<br /><br />Start time:2020-10-28 10:49:19.225<br />Nr.of iterations: 1 loops<br />Page size : 1 KBytes<br />RandomAccessFile write=231,177,333 read=733,524,355 (bytes/sec), CPUtime=11671 (millSec)<br />BufferedStreamFile write=66,562,662 read=335,627,663 (bytes/sec), CPUtime=36884 (millSec)<br />BufferedChannelFile write=215,533,571 read=334,859,385 (bytes/sec), CPUtime=15634 (millSec)<br />MemoryMappedFile write=519,006,588 read=761,904,761 (bytes/sec), CPUtime=6647 (millSec)<br />End time:2020-10-28 10:50:34.827<br /><br /><br />Start time:2020-10-28 10:56:30.198<br />Nr.of iterations: 1 loops<br />Page size : 4 KBytes<br />RandomAccessFile write=342,017,368 read=1,321,929,966 (bytes/sec), CPUtime=30170 (millSec)<br />BufferedStreamFile write=137,500,419 read=332,481,026 (bytes/sec), CPUtime=84231 (millSec)<br />BufferedChannelFile write=334,558,523 read=392,487,543 (bytes/sec), CPUtime=45373 (millSec)<br />MemoryMappedFile write=351,905,150 read=478,364,963 (bytes/sec), CPUtime=40418 (millSec)<br />End time:2020-10-28 10:59:58.12<br /><br /><br />Start time:2020-10-28 11:01:24.82<br />Nr.of iterations: 1 loops<br />Page size : 8 KBytes<br />RandomAccessFile write=341,504,085 read=1,449,911,504 (bytes/sec), CPUtime=59296 (millSec)<br />BufferedStreamFile write=261,896,769 read=291,810,636 (bytes/sec), CPUtime=118721 (millSec)<br />BufferedChannelFile write=329,730,926 read=396,726,233 (bytes/sec), CPUtime=91002 (millSec)<br />MemoryMappedFile write=309,991,864 read=429,947,253 (bytes/sec), CPUtime=90976 (millSec)<br />End time:2020-10-28 11:07:36.88Gaborhttps://www.blogger.com/profile/11184552580728910695noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-44135696755260905632018-06-08T01:38:20.796+01:002018-06-08T01:38:20.796+01:00I changed this test, so that each test would write...I changed this test, so that each test would write a byte array, instead of a single byte, also added FileOutputStream and BufferedOutputStream. Results are for Amazon EC2 c4.2xl instance.<br /><br />File size 409mb<br /><br />Test bytes/second write speed<br />RandomAccessFile.byte[]-rw 1,870,319,634<br />RandomAccessFile.byte[]-rw 1,878,899,082<br />RandomAccessFile.byte[]-rw 1,878,899,082<br />BufferedOutputStream-FileOutputStream 156,634,799<br />BufferedOutputStream-FileOutputStream 127,126,008<br />BufferedOutputStream-FileOutputStream 127,047,146<br />FileOutputStream 127,244,485<br />FileOutputStream 127,126,008<br />FileOutputStream 127,204,968<br />RandomAccessFile.ByteBuffer-rw 1,587,596,899<br />RandomAccessFile.ByteBuffer-rw 1,836,771,300<br />RandomAccessFile.ByteBuffer-rw 1,870,319,634<br />RandomAccessFile.DirectByteBuffer-rw 1,853,393,665<br />RandomAccessFile.DirectByteBuffer-rw 1,969,230,769<br />RandomAccessFile.DirectByteBuffer-rw 1,950,476,190<br />RandomAccessFile.MappedByteBuffer-rw 2,202,150,537<br />RandomAccessFile.MappedByteBuffer-rw 2,226,086,956<br />RandomAccessFile.MappedByteBuffer-rw 2,226,086,956<br />WritableByteChannel.MappedByteBuffer-rw 2,133,333,333<br />WritableByteChannel.MappedByteBuffer-rw 2,214,054,054<br />WritableByteChannel.MappedByteBuffer-rw 2,226,086,956<br />asadahttps://www.blogger.com/profile/05058939743259789030noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-54032775790195864122016-05-17T21:41:27.728+01:002016-05-17T21:41:27.728+01:00Repeated test on Win10 x64, i5-4460, 16GB RAM and ...Repeated test on Win10 x64, i5-4460, 16GB RAM and MX250 500GB SSD:<br />JVM: HotSpot 1.8.0_91<br />400MB<br /><br />RandomAccessFile write=414 155 712 read=1 190 697 674 bytes/sec<br />RandomAccessFile write=538 947 368 read=1 190 697 674 bytes/sec<br />RandomAccessFile write=417 959 183 read=1 183 815 028 bytes/sec<br />RandomAccessFile write=418 813 905 read=1 204 705 882 bytes/sec<br />RandomAccessFile write=419 672 131 read=1 219 047 619 bytes/sec<br /><br />BufferedStreamFile write=47 694 457 read=351 587 982 bytes/sec<br />BufferedStreamFile write=282 093 663 read=360 246 262 bytes/sec<br />BufferedStreamFile write=257 934 508 read=312 910 618 bytes/sec<br />BufferedStreamFile write=258 912 768 read=312 910 618 bytes/sec<br />BufferedStreamFile write=256 480 901 read=312 671 755 bytes/sec<br /><br />BufferedChannelFile write=395 748 792 read=425 779 625 bytes/sec<br />BufferedChannelFile write=260 559 796 read=424 016 563 bytes/sec<br />BufferedChannelFile write=308 433 734 read=1 058 397 932 bytes/sec<br />BufferedChannelFile write=308 433 734 read=426 222 684 bytes/sec<br />BufferedChannelFile write=306 816 479 read=428 451 882 bytes/sec<br /><br />MemoryMappedFile write=846 280 991 read=918 385 650 bytes/sec<br />MemoryMappedFile write=476 279 069 read=505 055 487 bytes/sec<br />MemoryMappedFile write=498 296 836 read=930 909 090 bytes/sec<br />MemoryMappedFile write=495 883 777 read=928 798 185 bytes/sec<br />MemoryMappedFile write=495 883 777 read=922 522 522 bytes/sec<br /><br />8GB<br /><br />RandomAccessFile write=399 707 245 read=1 216 332 590 bytes/sec<br />RandomAccessFile write=527 393 291 read=1 123 885 306 bytes/sec<br />RandomAccessFile write=337 870 164 read=1 311 139 564 bytes/sec<br />RandomAccessFile write=350 775 027 read=1 436 436 963 bytes/sec<br />RandomAccessFile write=334 503 879 read=1 415 831 316 bytes/sec<br /><br />BufferedStreamFile write=40 273 735 read=354 463 242 bytes/sec<br />BufferedStreamFile write=251 550 697 read=349 622 295 bytes/sec<br />BufferedStreamFile write=270 033 292 read=291 364 347 bytes/sec<br />BufferedStreamFile write=269 093 059 read=307 530 595 bytes/sec<br />BufferedStreamFile write=272 684 907 read=298 901 740 bytes/sec<br /><br />BufferedChannelFile write=337 605 604 read=432 980 972 bytes/sec<br />BufferedChannelFile write=243 172 643 read=419 801 168 bytes/sec<br />BufferedChannelFile write=295 058 348 read=1 134 940 426 bytes/sec<br />BufferedChannelFile write=304 557 959 read=452 022 292 bytes/sec<br />BufferedChannelFile write=301 597 820 read=438 450 010 bytes/sec<br /><br />MemoryMappedFile write=484 160 756 read=577 959 644 bytes/sec<br />MemoryMappedFile write=389 631 391 read=438 145 156 bytes/sec<br />MemoryMappedFile write=391 194 307 read=505 273 545 bytes/sec<br />MemoryMappedFile write=400 175 858 read=516 943 270 bytes/sec<br />MemoryMappedFile write=399 531 798 read=515 966 492 bytes/seckstepienhttps://www.blogger.com/profile/16449659207049981080noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-21655229575440424652013-07-01T09:43:30.282+01:002013-07-01T09:43:30.282+01:00Normal behaviour is not to force the pages to disk...Normal behaviour is not to force the pages to disk. It would only make sense for a database transaction log write at commit points. I don't understand why you think it is relevant for this test?<br /><br />The point is not to test actual disk performance but to test the APIs from Java to the OS filesystem.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-28452685739507280642013-06-30T13:22:07.580+01:002013-06-30T13:22:07.580+01:00Why didn't you use flushing to disk and cleari...Why didn't you use flushing to disk and clearing of disk buffer?<br />BufferedOutputStream close() method includes flushing to disk and thus slower. If you append to other tests <br /><br />for RandomAccessFile<br />RandomAccessFile raf;<br />raf.getFD().sync();<br /><br />and for FileChannel<br />channel.force(true);<br /><br />and for MappedByteBuffer <br />buffer.force();<br /><br />you'll see that write performance in general is same (~10% difference only)<br /><br />And same situation with read performance if you'll do clearing of disk buffer before read (sync; echo 3 > /proc/sys/vm/drop_caches)<br />Only MappedByteBuffer read test 70% faster than others on my environment.Anonymoushttps://www.blogger.com/profile/12120786482615546261noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-13709137575901624162012-03-05T10:00:00.502+00:002012-03-05T10:00:00.502+00:00FileInputStream / FileOutputStream and RandomAcces...FileInputStream / FileOutputStream and RandomAccesFile share same native code so speed difference is in byte vs byte[] read / write on java source levelnicityhttps://www.blogger.com/profile/12472362059925135669noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-3890248239126452232012-03-03T01:20:13.411+00:002012-03-03T01:20:13.411+00:00Memory mapped files are really fast for read when ...Memory mapped files are really fast for read when they are hot (loaded into memory by previous I/O).Paulo Gasparhttps://www.blogger.com/profile/10807621960030593884noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-29750088713333212212012-02-25T08:11:18.458+00:002012-02-25T08:11:18.458+00:00To me if you are looking for best IO performance t...To me if you are looking for best IO performance than use nio and <a href="http://javarevisited.blogspot.com/2012/01/memorymapped-file-and-io-in-java.html" rel="nofollow">Memory Mapped File in Java</a> is best if your application can use it. Thanks for analysis, I was also had same opinion for RandomAccessFile and I still use it:)javin paulhttps://www.blogger.com/profile/15028902221295732276noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-55047912455999186312012-01-26T17:36:20.111+00:002012-01-26T17:36:20.111+00:00Can you post your code to github, or somewhere sim...Can you post your code to github, or somewhere similar, so others can see the approach and confirm the findings? It also needs to be tested with a much larger file to take caching out of the equation.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-85617887754850700272012-01-26T17:20:51.448+00:002012-01-26T17:20:51.448+00:00I agree that with a Buffer you could do _less_ bui...I agree that with a Buffer you could do _less_ building up in advance, but you are testing what is essentially the worst case -- performing IO a single byte at a time. If you want to compare apples to apples, you should be calling RandomAccessFile.write(int), to write a single byte at a time. <br /><br />But nobody ever does that ;) I think what you're detecting here is that the JVM is really, really good at optimizing operations over local byte arrays.<br /><br />I created some additional tests and used byte-array methods instead. The results are pretty much as I expected. This is on Windows 7 64 bit. Buffered streams win slightly over RandomAccessFile. BufferedChannel is about the same. Memory mapping the file doubles write performance and quadruples read performance. Here are the 400MB file results:<br /><br />RandomAccessFile write=375,435,380 read=627,258,805 bytes/sec<br />RandomAccessFile write=332,197,891 read=646,056,782 bytes/sec<br />RandomAccessFile write=308,201,655 read=651,192,368 bytes/sec<br />RandomAccessFile write=307,969,924 read=648,101,265 bytes/sec<br />RandomAccessFile write=307,738,542 read=678,145,695 bytes/sec<br />BufferedStreamFile write=192,481,203 read=249,603,900 bytes/sec<br />BufferedStreamFile write=181,640,798 read=256,641,604 bytes/sec<br />BufferedStreamFile write=178,009,561 read=155,859,969 bytes/sec<br />BufferedStreamFile write=169,116,432 read=155,682,250 bytes/sec<br />BufferedStreamFile write=174,446,337 read=153,236,064 bytes/sec<br />BufferedStreamFile2 write=344,201,680 read=787,692,307 bytes/sec<br />BufferedStreamFile2 write=314,592,933 read=827,474,747 bytes/sec<br />BufferedStreamFile2 write=328,468,323 read=795,339,805 bytes/sec<br />BufferedStreamFile2 write=322,265,932 read=811,089,108 bytes/sec<br />BufferedStreamFile2 write=288,247,712 read=819,200,000 bytes/sec<br />BufferedChannelFile write=167,937,679 read=330,322,580 bytes/sec<br />BufferedChannelFile write=172,245,584 read=349,190,110 bytes/sec<br />BufferedChannelFile write=146,077,032 read=622,492,401 bytes/sec<br />BufferedChannelFile write=145,557,924 read=624,390,243 bytes/sec<br />BufferedChannelFile write=145,248,226 read=626,299,694 bytes/sec<br />BufferedChannelFile2 write=310,303,030 read=656,410,256 bytes/sec<br />BufferedChannelFile2 write=313,629,402 read=662,783,171 bytes/sec<br />BufferedChannelFile2 write=310,538,286 read=670,376,432 bytes/sec<br />BufferedChannelFile2 write=306,586,826 read=672,577,996 bytes/sec<br />BufferedChannelFile2 write=304,988,830 read=675,907,590 bytes/sec<br />MemoryMappedFile write=248,845,686 read=300,513,573 bytes/sec<br />MemoryMappedFile write=232,199,546 read=296,382,054 bytes/sec<br />MemoryMappedFile write=299,196,493 read=358,355,205 bytes/sec<br />MemoryMappedFile write=298,107,714 read=347,413,061 bytes/sec<br />MemoryMappedFile write=297,026,831 read=341,049,125 bytes/sec<br />MemoryMappedFile2 write=479,625,292 read=1,237,462,235 bytes/sec<br />MemoryMappedFile2 write=482,449,941 read=1,047,570,332 bytes/sec<br />MemoryMappedFile2 write=564,965,517 read=1,244,984,802 bytes/sec<br />MemoryMappedFile2 write=563,411,279 read=1,233,734,939 bytes/sec<br />MemoryMappedFile2 write=561,095,890 read=1,241,212,121 bytes/secrossjudsonhttps://www.blogger.com/profile/15233290990299132866noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-45597918950210093442012-01-26T16:35:33.850+00:002012-01-26T16:35:33.850+00:00Ross,
I believe the point of using ByteBuffers an...Ross,<br /><br />I believe the point of using ByteBuffers and Channels, or BufferedStreams, is so that you do not need to build up a buffer in advance. They are providing that feature by their design, otherwise why use them? If you build up a buffer in advance, I think you will find it slower because the buffer gets copied twice. The important cost is the number of times you ultimately call the IO sub-system out of your user process into the kernel.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-72706913440838498632012-01-26T16:23:06.766+00:002012-01-26T16:23:06.766+00:00I am curious about the generated code; I'll ta...I am curious about the generated code; I'll take a look at it. You don't agree that it would be fairer across methods to assemble the byte[] and call each IO type the same number of times?rossjudsonhttps://www.blogger.com/profile/15233290990299132866noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-15627353145949397592012-01-26T09:08:50.483+00:002012-01-26T09:08:50.483+00:00A lot of the benefits of RandomAccessFile are the ...A lot of the benefits of RandomAccessFile are the patterns it encourages based on its API design. <br /><br />However I cannot agree with your conclusions. If you look at the generated asm code you can see that Hotspot has no trouble inlining the use of ByteBuffer and even applying intrinsics. The -server JIT complier is very aggressive about inlining. By default Hotspot will not inline a method greater than 35 bytecodes. You can experiment by setting -XX:MaxInlineSize=35. Note this is bytecodes and not bytes. the "external method invocations" as you put it are well below this threshold.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-37919160224742181002012-01-26T05:36:12.814+00:002012-01-26T05:36:12.814+00:00Your RandomAccessTest stays completely inside of i...Your RandomAccessTest stays completely inside of its loop until it needs to write a byte []. Only then does it make a method call and leave the loop. The other methods all have 4096 times as many external method invocations in the inner loop.<br /><br />A fairer test would be to assemble the byte[] the same way with each method, then write that. Or, actually write a byte at a time to the RandomAccessFile.<br /><br />Hotspot isn't going to inline complex methods.rossjudsonhttps://www.blogger.com/profile/15233290990299132866noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-42407072333172749822012-01-19T07:14:40.028+00:002012-01-19T07:14:40.028+00:00Falcon,
I have done this for sockets but not in a...Falcon,<br /><br />I have done this for sockets but not in a while. Good reminder to stay current. Last time I checked basic blocking sockets were greater throughput and lower-latency than NIO sockets. You obviously need a thread per socket so 64-bit is required for a large number of clients. Frameworks like Netty and Mina I've found add a significant overhead.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-34956133750985532012012-01-19T00:04:24.385+00:002012-01-19T00:04:24.385+00:00Seven,
You are absolutely right. Good spot thanks...Seven,<br /><br />You are absolutely right. Good spot thanks. I'll re-run the tests and post the results. Initial runs suggest write performance is closer to RandomAccessFile.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-29506202690531557812012-01-18T21:06:06.296+00:002012-01-18T21:06:06.296+00:00Hi,
The write part of BufferedChannelFile is flaw...Hi,<br /><br />The write part of BufferedChannelFile is flawed because channel.write(buffer) really writes nothing since the buffer is not flipped. So buffer.flip() is in order prior of calling channel.write().sevenhttps://www.blogger.com/profile/15623262172695056490noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-12702569116462342662012-01-11T19:35:21.783+00:002012-01-11T19:35:21.783+00:00Very interesting. Do you have a similar analysis f...Very interesting. Do you have a similar analysis for sockets? Is it better to use basic sockets, as they have always existed in java (I realize the logic beneath the API has changed greatly)? Is it better to use NIO or even third-party tools such as netty?falconhttps://www.blogger.com/profile/12277230403055479892noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-54611523537092216542011-12-29T10:02:50.525+00:002011-12-29T10:02:50.525+00:00Repeated the test on:
- Java 1.6.0_26 (HotSpot 64-...Repeated the test on:<br />- Java 1.6.0_26 (HotSpot 64-Bit Server build 20.1-b02)<br />- Xeon 2GHz cpu<br />- Debian Squeeze<br />- 48G RAM<br />- hardware RAID1 with rotating disks (can't figure out which)<br /><br />RandomAccessFile write=71,871,627 read=1,022,083,593 bytes/sec<br />RandomAccessFile write=91,133,607 read=1,021,446,384 bytes/sec<br />RandomAccessFile write=85,629,468 read=976,516,867 bytes/sec<br />RandomAccessFile write=87,691,879 read=981,430,454 bytes/sec<br />RandomAccessFile write=87,300,318 read=977,915,721 bytes/sec<br /><br />BufferedStreamFile write=58,101,351 read=235,788,504 bytes/sec<br />BufferedStreamFile write=141,629,639 read=223,130,141 bytes/sec<br />BufferedStreamFile write=124,271,844 read=131,937,510 bytes/sec<br />BufferedStreamFile write=146,568,381 read=132,372,426 bytes/sec<br />BufferedStreamFile write=144,410,950 read=131,340,986 bytes/sec<br /><br />BufferedChannelFile write=326,569,663 read=325,596,184 bytes/sec<br />BufferedChannelFile write=341,960,260 read=327,391,895 bytes/sec<br />BufferedChannelFile write=346,839,408 read=1,081,309,398 bytes/sec<br />BufferedChannelFile write=349,041,329 read=1,080,026,367 bytes/sec<br />BufferedChannelFile write=346,531,302 read=1,066,250,162 bytes/sec<br /><br />MemoryMappedFile write=280,202,490 read=233,636,596 bytes/sec<br />MemoryMappedFile write=190,188,749 read=262,479,974 bytes/sec<br />MemoryMappedFile write=180,190,484 read=254,884,878 bytes/sec<br />MemoryMappedFile write=189,673,535 read=238,236,491 bytes/sec<br />MemoryMappedFile write=164,501,295 read=262,740,947 bytes/sec<br /><br />The system was mostly idle. Dips however, can be explained by other activity.Erik van Oostenhttps://www.blogger.com/profile/15976519439979651010noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-56943285323976268482011-12-29T08:17:11.117+00:002011-12-29T08:17:11.117+00:00id,
Path.copyTo() does not exist as a method in m...id,<br /><br />Path.copyTo() does not exist as a method in my JDK 7. Can you post a snipet of code for what you expect to see?<br /><br />If I guess to what you are comparing can you expand on how this is similar to the other tests if it is simply copying one file to another? I just don't understand how it is like-for-like.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-50626808670170557822011-12-28T22:10:27.027+00:002011-12-28T22:10:27.027+00:00Could you compare with the Path.copyTo() from java...Could you compare with the Path.copyTo() from java 7?<br />At least in the unix case, it uses native code. It could be interesting to see the difference.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-42250445029341104212011-12-27T11:30:16.691+00:002011-12-27T11:30:16.691+00:00"If I use FileInputStream/FileOutputStream di..."If I use FileInputStream/FileOutputStream directly (no Buffered*Stream) with write/read(byte[PAGE_SIZE]) then the read is significantly better and almost RandmonAccessFile levels. However the write only shows marginal improvement."<br /><br />Thanks. Good to know.<br /><br />Best,<br />IsmaelIsmael Jumahttps://www.blogger.com/profile/17398483226873559286noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-72769755943196861192011-12-27T11:13:44.486+00:002011-12-27T11:13:44.486+00:00> You suppose overhead of not-inlined function ...> You suppose overhead of not-inlined function call can make accountable infuence on IO performance? <br /><br />I think it is likely to be case of what intrinsics get applied during JIT'ing and when.<br /><br />> By the way -- did you try different buffer sizes, other from 4K? My experiments show what difference between NIO/IO tend to decrease, and become ~10% only with buffer size about 128-512K (for my hardware, sure). <br /><br />With a larger buffer then the chunking of this buffer down to pages/blocks of the storage will be happening outside of Java, i.e. in the kernel for the file system. So the amount of work on the Java side is relatively less with a larger buffer.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-29126018425765816752011-12-27T11:00:45.797+00:002011-12-27T11:00:45.797+00:00> I agree that it would be interesting to see t...> I agree that it would be interesting to see the results of buffering to a byte[] and then calling FileOutputStream.write(byte b[]).<br /><br />If I use FileInputStream/FileOutputStream directly (no Buffered*Stream) with write/read(byte[PAGE_SIZE]) then the read is significantly better and almost RandmonAccessFile levels. However the write only shows marginal improvement.Martin Thompsonhttps://www.blogger.com/profile/15893849163924476586noreply@blogger.comtag:blogger.com,1999:blog-5560209661389175529.post-68959520885971289892011-12-27T10:55:22.368+00:002011-12-27T10:55:22.368+00:00> I'd guess it is an optimisation issue. Pr...> I'd guess it is an optimisation issue. Probably something related to OSR like I discussed in my last post. The RandomAccessFile example is very simple and thin layer over file access.<br /><br />You suppose overhead of not-inlined function call can make accountable infuence on IO performance? Seems surprising to me<br /><br />By the way -- did you try different buffer sizes, other from 4K? My experiments show what difference between NIO/IO tend to decrease, and become ~10% only with buffer size about 128-512K (for my hardware, sure).Ruslan Chereminhttps://www.blogger.com/profile/01023948540752159657noreply@blogger.com