http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660MikeS: Absolutely right. It's 10% vs 21% improvement. Btw. great video about latency issues http://video.google.com/videoplay?docid=-4714369049736584770&ei=pZmNSL-gOZ_q2gKNk53AAw http://ayende.com/3448/some-observations-on-saving-to-file#comment7http://ayende.com/3448/some-observations-on-saving-to-file#comment7Mon, 28 Jul 2008 11:03:54 GMTAyende, re Tobi: I think he means that 10% squared != 100% ; http://ayende.com/3448/some-observations-on-saving-to-file#comment6http://ayende.com/3448/some-observations-on-saving-to-file#comment6Mon, 28 Jul 2008 00:08:27 GMTTobi, Can you explain? http://ayende.com/3448/some-observations-on-saving-to-file#comment5http://ayende.com/3448/some-observations-on-saving-to-file#comment5Sun, 27 Jul 2008 21:11:31 GMTJustin, Those are great points, thanks. http://ayende.com/3448/some-observations-on-saving-to-file#comment4http://ayende.com/3448/some-observations-on-saving-to-file#comment4Sun, 27 Jul 2008 21:10:41 GMTIs it just me or is anybody else worried about evan's "quared" example. ;-) http://ayende.com/3448/some-observations-on-saving-to-file#comment3http://ayende.com/3448/some-observations-on-saving-to-file#comment3Sun, 27 Jul 2008 20:38:00 GMTThe difference is even more apparent if you use a more reasonably sized buffer. 64K would work, although I think 1MB is more typical these days. Something else to consider is ensuring that you write defragmented files when possible. The OS (Windows) will not do this for you, so it's your responsibility to call FileStream.SetLength if you have a good idea how big the file will get. (I've even found this to be beneficial on Linux where the OS does a better job about avoiding fragmentation.) Also as SSD's become the norm, then we may want to avoid writing data smaller than N bytes so as to avoid wearing out the drive prematurely. (My understanding is that NAND Flash always writes in N byte blocks where N is typically 16K-128K, and that you have a limited number (1mil) of these writes before the drive fails.) Here are a few more data points ... Vista 32, 2.66Ghz Core 2, Samsung 7200rpm disk, writethrough, 1MB bufsize, defragged file 4000000 81 5583 83 4150 Same, but with WD Raptor 10Krpm disk 4000000 97 1683 99 1731 Same, but with thumb drive 4000000 395 10699 293 140377 Vista 32, 2.5 Ghz Core 2 laptop, Memoright SSD, writethrough, 1MB bufsize, defragged file 4000000 197 2458 117 2117 http://ayende.com/3448/some-observations-on-saving-to-file#comment2http://ayende.com/3448/some-observations-on-saving-to-file#comment2Sat, 26 Jul 2008 21:36:38 GMT"I wonder if this means that I should treat making a disk call as a remote call, and use the same optimization techniques there as well." As long as you are focusing on what's really important for your application, I'd say most definitely. If you want a different way to think about this problem, you can think of disk seek as latency and disk throughput as bandwidth. Everything else still applies. It's also interesting to note that, in the recent history of computer architecture, bandwidth and latency have had a predictable relationship. There's a rule of thumb that says the improvement in bandwidth will be at least the square of improvement in latency. That means a 10% improvement in latency will usually give you at least a 100% improvement in bandwidth in the next generation of hardware. That's held true for cpu, disk, network, and memory technology. So, to put that into a format that's practical, over time, latency in your system will see incremental improvements. Bandwidth will see at least exponential improvements. Optimize and design accordingly. http://ayende.com/3448/some-observations-on-saving-to-file#comment1http://ayende.com/3448/some-observations-on-saving-to-file#comment1Sat, 26 Jul 2008 17:53:12 GMT