[uClibc]Performance/profiling

Erik Gustavsson cyrano at algonet.se
Fri Jun 28 08:22:41 UTC 2002


On Thu, 27 Jun 2002 12:19:43 -0600
"(Manuel Novoa III)" <mjn3 at codepoet.org> wrote:

> Hello,
> 
> On Thu, Jun 27, 2002 at 07:13:25PM +0200, Erik Gustavsson wrote:
> > I'm working on a linux-based digital music player, and I was hoping to use uclibc (because of it's size, obviously). Unfortunately my main app (which currently only supports MP3, using the MAD decoder) went from 9% to 24% CPU usage on my development system when I switched from glibc to uclibc. This makes it too slow for the target system. 
> 
> It would be helpful to know what functions get linked in by your
> decoder.  But one thought I had is that if you're using stdio to 
> read and write data, some of the speed difference could be due to
> buffering.  By default, uClibc uses 256 byte buffers on streams.
>

What is a good way to find out what functions are linked in? (except looking at the source manually). The only functions I know get called in the decoding loop are memcpy(), memmove() and some pthread_mutex stuff.

I tried changing the buffer size to 4096 (at least I'm pretty sure I did) and it had some marginal effect on performance (1% CPU at best). 

Interestingly enough, just the bare decoder is just as fast using uClibc as with glibc. The slowness comes when adding my main app around it, although it doesn't really do a whole lot more work. In it's current state it has a VFS abstraction layer that not much more than a big wrapper for open() and read() and a soundcard output layer that's not much more than a wrapper for open() and write(). 

The app is threaded however, there are about 3-4 threads doing practically nothing while one thread does all the decoding work. Are there any known problems with the pthread stuff in uClibc? Is it based on the "real thing" or written from scratch? 

> > I'm thinking (hoping) it's one or two functions that are horribly unoptimized that I can fix or work around but unfortunately I can't seem to profile the code with uclibc,  at least not the "usual" way. Is there any profiling support in uclibc? I couldn't find any information on this using google...
> 
> One of the things on Erik's TODO list is to get profiling working.
> I've asked him about that myself.  ;-)
> 

It would sure be useful right now...

/cyr



More information about the uClibc mailing list