Poor read() performance, and I can't profile it

[Kris Kennaway]

Kirk Strauser wrote:
> Kris Kennaway wrote:
> 
>> No, if it's reading in 16 byte units it will explain the terrible 
>> performance.
> 
> No, it's actually doing 4096-byte reads.  That was just an example of 
> what I meant.

I don't understand what you meant by "It's also doing a lot of lseek()s 
to what is likely the current position anyway (example: seek to 0x00, 
read 16 bytes, seek to 0x10, etc.)." then.  Please show a typical part 
of the ktrace output.

Kris

 >  Since I wrote that, though, I wrote a program to do
> 1,000,000 seeks to position 0, and it ran immeasurably fast.  I'm 
> guessing that lseek() is optimized to not do anything if you ask it to 
> move to the position you're already at.
> 
> Any other thoughts?  There definitely aren't any setbuf() calls, and no 
> matter what it still takes 100 times more kernel overhead on Linux than 
> FreeBSD.  Speaking of which, I think my next experiment will be to try 
> the Linux binaries on FreeBSD and see if it behaves similarly.