Remove x number of lines from beginning of file
smorrey at gmail.com
Fri Oct 26 10:24:49 MDT 2007
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.
On 10/26/07, Jonathan Ellis <jonathan at utahpython.org> wrote:
> On 10/26/07, Alex Esplin <alex.esplin at gmail.com> 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
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
More information about the PLUG