I totally get what you mean about being IO bound, however as I said earlier, there is still CPU time involved, saving 1% may not sound like a lot but it could add up, and after the initial development cost is recouped that 1% becomes free. However I believe that by not incurring the overhead of loading a general purpose utility your savings are much more than 1%. That said my way using streams was certainly not ideal, because you do incur the whole stream overhead penalty, but I figured that was counterbalanced by the speed at which the development could proceed.
Additionally, in what real world application of something like this, would you be able to use a file system hack like that, and/or change the file system all together? If he's going to do that, why not upgrade the machine, throw in SATA go with a stripped RAID configuration and so forth. Either way the file system hacking bit seems like a cool idea, but how does it quantifiably increase IO throughput? Seems like adding more layers of stuff for the IO operation to pass through would actually slow things down a bit. Sincerely, Steve On 10/26/07, Jonathan Ellis <[EMAIL PROTECTED]> wrote: > On 10/26/07, Alex Esplin <[EMAIL PROTECTED]> wrote: > > That's strange, I was trying to help the OP do something a little > > faster in as easy a way as possible. Granted, if I wasn't in the > > middle of a particularly trying semester right now it would be fun to > > hunt around for an efficiency class changing way of doing it, but > > given real-life time constraints, sometimes a quicker, easier solution > > just has to work for a while. > > The whole point is that for the OP your "quicker, easier" _might_ save > a whole 1%. _It doesn't make a difference to optimize CPU when you're > IO-bound_. > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
