Remove x number of lines from beginning of file

Steve smorrey at
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> wrote:
> On 10/26/07, Alex Esplin <alex.esplin at> 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:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */

More information about the PLUG mailing list