Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: A nasty inefficieny in file.c?

Re: A nasty inefficieny in file.c?

From: Jens Arnold <arnold-j_at_t-online.de>
Date: 2006-07-14

On 14.07.2006, postmaster@diffenbach.org 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
Received on Fri Jul 14 07:24:55 2006


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa