This is historic... one should make a new investigation.
What I can say that a quick test of pre0.59s versus 1.7.3 with generic decoder on my x86-64 GNU/Linux box is not able to call a winner (or looser, for that matter).
Though, 1.8.0 will make the new libmpg123 a winner, because there is new optimization code going on!

The move to libmpg123 means some more code separation / interfacing and especially the move of any local static variables into the mpg123_handle to make multiple stream handling possible.
That may very well have an impact on performance of the mpg123 decoder.
I made some tests, even using gcc's -pg option and gprof, with mixed result: SSE and MMX on my Thinkpad X31 are slower, especially the asm synth funtion, while the generic code is fine.
On the other hand, on a K6-3+ using the same gcc version 4.1.2, the library based mpg123 is _faster_ for MMX and 3DNowExt.
Epecially the mmx synth is faster... while the 3DNowExt synth is slower, too (it's the same code as SSE synth, just calling different dct64) - but speedups in other regions still make 3DNowExt of the library mpg123 more efficient.

What I can clearly say is that dropping the multi-cpu support via ./configure --with-cpu does help in for both monolithic and library mpg123, but that is no wonder as it removes indirection.
The main point stays, though: On my Thinkpad the library is slow, on the K6-3+ it's fast.

What's the point to get here? I am not sure. We're depending on the compiler optimization (btw: Intel Compiler doesn't change the relation for the Thinkpad; not tested on the K6).
I guess that for my Thinkpad another gcc version could invert the picture again...
Also, I am not sure how far I should trust the gprof analysis... but it can be right; even when there is no apparent cause for the speed difference in the code itself, it could be some effect of cache and memory access.
Some reordering of instructions and data... for sure that happened.

I'll need further numbers to conclude anything about the (positive/negative) impact my code changes have.

OK, ran the test of trunk against branches/mpg123lib on my media box with AMD Geode (AthlonXP, actually):

thomas@kiste:~$ for i in mpg123-lib mpg123-trunk; do for cpu in mmx 3dnowext sse; do echo $i $cpu; time $i/src/mpg123 --cpu $cpu -q -t /thorma/var/music/metallica/ride_the_lightning/*.mp3; done; done
mpg123-lib mmx

real	0m25.949s
user	0m25.395s
sys	0m0.534s
mpg123-lib 3dnowext

real	0m25.442s
user	0m24.863s
sys	0m0.558s
mpg123-lib sse

real	0m25.794s
user	0m25.214s
sys	0m0.562s
mpg123-trunk mmx

real	0m26.650s
user	0m26.004s
sys	0m0.626s
mpg123-trunk 3dnowext

real	0m25.886s
user	0m25.262s
sys	0m0.600s
mpg123-trunk sse

real	0m25.695s
user	0m25.136s
sys	0m0.539s
thomas@kiste:~$ for i in mpg123-lib mpg123-trunk; do for cpu in 3dnow; do echo $i $cpu; time $i/src/mpg123 --cpu $cpu -q -t /thorma/var/music/metallica/ride_the_lightning/*.mp3; done; done
mpg123-lib 3dnow

real	0m33.011s
user	0m32.365s
sys	0m0.621s
mpg123-trunk 3dnow

real	0m32.830s
user	0m32.192s
sys	0m0.619s


You can't really make a decision there. It's tight.
What worries me a bit is the total loose of 3DNow against MMX - should it be that drastic?
Well, it's higher quality, at least.


-- 
Thomas.

