5 Jul
2011
5 Jul
'11
1:30 a.m.
Dan Muresan wrote:
Whaaat? You're kidding me right?
I haven't measured it, but my educated guess is that if you're
reading 16384 frames at a time from a FLAC file on current hardware,
then the difference between reading st_blksize sized blocks and
non-st_blksize sized blocks will be absolutley swamped, by disk
latencies, cache latencies, scheduling latencies and file
decoding overhead.
You might want to google the term "premature optimisation".
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
> > I
never much liked the VIO layer. It was only ever added because
> > a large number of people requested it. I think its fragile and
> > it exposes too much of libsndfile internals to the user.
There is one remaining issue that I have discovered while writing
jack-file, and which can only be addressed via a VIO layer of some
sort. While reading a FLAC file, the sndfile request size stream looks
like
8188, 8188, 8188, 8192 etc (bytes)
This is with the user continuously requesting 16384 frames. You will
notice that these are uneven block sizes. If I understand correctly
e.g. the stat(2) page, these are inefficient syscalls:
"The st_blksize field [of a struct stat] gives the "preferred"
blocksize for efficient file system I/O. (Writing to a file in smaller
chunks may cause an inefficient read-modify-rewrite.)"
Without a VIO layer (or a libsndfile user-space cache), this is not
solvable by the user at higher abstraction layers.