[pulseaudio-discuss] Hard-coded allocation of 64 MB of memory upfront too big in some scenarios

[rdiezmail-pulseaudio at yahoo.de]

> There is no need to make this configurable. On modern
> operating systems memory allocation works via overcommitting:
> although we allocate this 64mb pool on startup, it is not actually used
> right-away and thus does not actually consume any precious
> memory.

As I stated on my original message, my embedded PowerPC target hasn't got shared memory (i.e. not configured in the kernel), so all allocations are routed through malloc. At least in debug builds, allocations are filled with 0xBAADF00D or a similar pattern in advance, so I had to modify the source code because it was consuming half of the available memory before doing anything.

I've noticed there is a tendency to automatically think in terms of the PulseAudio server. I'm writing a client that connects to the audio server via the network, and, in a client environment, I think it's bad practice to allocate 64 MB of memory when in fact you'll be using just a tiny portion of it most of the time.

Even for the server side, I also think it's bad practice not to automatically and periodically release memory to the OS: that probaby means that the server will always hold as much memory as the peak usage (some maximum reached in the past). At the very least, that forever ties up swap space for other applications.

Allocating a big, fixed-sized chunk of memory in advance, in the hope that the OS will optimize it away if never used, is also questionable. It does not work if the OS is not smart enough (see embedded Linux at www.uclinux.org). It tends to obscure the real memory ussage of the application by distorting the memory statistics (is there a way to find out how much memory the client library allocated?). I raises user questions all the time (it makes the app look big) which need to be constantly explained. It reserves swap file space away that other applications cannot use, it may force you to have a swap file in the first place.

All that could be fine for a single-instance PulseAudio server running on a fully-featured PC. But the trouble is, all those negative aspects are automatically transferred to every client application that uses the PulseAudio client library. I wish the library user could specify the malloc and free routines to use (like the zlib library does); after all, the host application may implement its own memory pool schema.


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. 
http://mail.yahoo.com