On Sun, Nov 11, 2007 at 09:52:21AM -0800, Randall Hyde wrote: >why C's code was so much faster, I dug into the source code and discovered >that open/read/write/etc. use *buffered* I/O (which explains why "dd" >performs so well).
open/read/write/etc. do _not_ do any buffering in userland. This is
easily demonstrated using eg
$ ktrace dd if=/dev/random of=/dev/null count=50 bs=1
The relevant part of the output is:
30532 dd CALL read(0x3,0x2820410c,0x1)
30532 dd GIO fd 3 read 1 byte
")"
30532 dd RET read 1
30532 dd CALL write(0x4,0x2820410c,0x1)
30532 dd GIO fd 4 wrote 1 byte
")"
30532 dd RET write 1
30532 dd CALL read(0x3,0x2820410c,0x1)
30532 dd GIO fd 3 read 1 byte
"a"
30532 dd RET read 1
30532 dd CALL write(0x4,0x2820410c,0x1)
30532 dd GIO fd 4 wrote 1 byte
"a"
30532 dd RET write 1
>At this point I'm not sure why FreeBSD's API call is so slow
You have yet to provide any evidence of this. So far, you can only
demonstrate it on your application - which strongly suggests it's a
problem with your code, rather than FreeBSD.
Have you check the ktrace output from your code or time(1)d it as
suggested?
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an RFC2821-compliant MTA.
pgptNezorRMJ0.pgp
Description: PGP signature
