>You're right that the tests are somewhat artificial and they're not benchmarking best practices such as StringBuilders where such can be used. Another thing they gloss over is the results are almost certainly not "sustainable" (i.e. continuous load vs "bursts"). They get excellent results for the write-to-disk option as long as the write cache is not overwhelmed; once that happens write performance can be no higher than the disk subsystem IOPS, and is probably (much) less due to overhead/thrashing.
>
>Nonetheless I think the article is worthwhile:
>- It shows just how bad some rookie programming mistakes can be :)
>- It shows how good a modern virtual memory manager coupled with a write cache can be
>- There may be scenarios where you can't take full advantage of mutable types. In those cases, it's a warning not to get too carried away trying to minimize disk I/O, and to at least benchmark the direct I/O case to see if any optimization you're doing is making things better or worse ;)


agreed insofar as the title and conclusion could have been more on target to be of more use ;-))

>
>Speaking of sustained operation and disk IOPS, SSDs are a game changer in that area, 2 orders of magnitude faster than mechanical drives: http://en.wikipedia.org/wiki/IOPS . All other things being equal, makes the direct write to disk option that much more attractive ;)

For us DB guys most of the times (unless creating tons of reports) the random IOPS speedup is heaven sent. In the above specced scenario the pipe to disc is sequential, and there a well tuned HD is not that bad if running on a workstation and not bothered by too many other processes ;-)

My old trick of having separate physical discs for source and target for report creation or staging scenarios cuts a lot into the speedup witnessed by switching to SSD.