[MPlayer-dev-eng] [PATCH] replacement for internal mpg123 fork (mp3lib), Final version?

[Thomas Orgis]

Am Sun, 16 May 2010 22:47:49 +0300
schrieb Uoti Urpala <uoti.urpala at pp1.inet.fi>: 

> That much difference from a single extra malloc/free per mpeg frame?
> That sounds unexpectedly large. Also MPlayer will allocate/free the data
> for each packet anyway. Or did the mpg123 code do more extra than just
> one allocation?

The old mpg123 does one malloc & memcpy per data block that's handed
in (and free later on). I observed the the performance effect when
switching back to the feeding in 1K blocks, then changing the block
size. Increasing to 4K brought the said improvement (figuring that 4K
might be a good memory block size on my architecture anyway). Increasing
further didn't make it better. Going to blocks of 333 bytes, I got about
the performance we have with the pts packets.

What I do wonder is how much the scale of the effect is specific to the
raw throughput measurement with -ao pcm .. i.e. if it's just the effect
of many malloc/frees happinging quickly in time, causing some
contention in the system? But then, I think it is to be expected to
have somewhat less efficiency of malloc/free with blocks below a
page size. Also I expect the acutal operating system's config to play a
big role. I observed massive differences in malloc/free performance
between Linux and Solaris (in a multithreaded context, though).

Apart from just accepting the sub-par performance with old mpg123
(which might or might not be relevant for realtime decoding), we do have
the option to feed data in larger blocks (1K might be fine, 2K ... 4K
perhaps too much) and dispensing with the pts timing, it's only a change
of very few lines in decode_a_bit. One might have a build/runtime switch
between the two feeding mechanisms.


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100516/033b9d5e/attachment.pgp>