On 14.07.2006, [EMAIL PROTECTED] wrote:
> ...
> rockbox. My profiling turned up a rather nasty inefficiency in
> file.c.
This is in fact not an inefficiency in file.c itself. It just
confirms what I suspect for quite some time; see below.
> File.c's readwrite function calls memcpy a couple of places.
> One of things it calls memcpy for is to copy "headbytes",
> whatever those are.
> file.c at line 490:
> /* any head bytes? */
> if ( file->cacheoffset != -1 ) {
> int offs = file->cacheoffset;
> int headbytes = MIN(count, SECTOR_SIZE - offs);
> if (write) {
> memcpy( file->cache + offs, buf, headbytes );
> file->dirty = true;
> }
> else {
> memcpy( buf, file->cache + offs, headbytes );
> }
> if (offs + headbytes == SECTOR_SIZE) {
> if (file->dirty) {
> int rc = flush_cache(fd);
> if ( rc < 0 ) {
> errno = EIO;
> return rc * 10 - 2;
> }
> }
> file->cacheoffset = -1;
> }
> else {
> file->cacheoffset += headbytes;
> }
> nread = headbytes;
> count -= headbytes;
> }
read() and write() allow arbitrary byte counts, but the FAT
driver only handles sectors. As the underlying storage media can
only handle whole sectors, this composition/decomposition has to
be done at some point.
For this purpose, file.c caches up to one sector worth of data.
"headbytes" is any new data that fits into the sector cache
when it's already dirty.
> What I'm finding is that headbytes is very often 1, so memcpy
> is being called to copy a single byte.
This is not an inefficiency in file.c itself, but in fact in
parts of rockbox using the file functions. These parts call
read() and write() for single bytes...
Regards, Jens
