Shaving megabytes: cplay and mcplay

A few months ago I mentioned mcplay as an alternative to the time-honored but unfortunately departed cplay. mcplay is intended to be a close mimic to the dead program, written in C as opposed to Python. At the time I made no real distinction between the two, since my concern was mostly with function, but as yasen mentioned, I should have.

I had a few extra moments today to tinker with both of those in Arch, and I believe yasen was right: On extremely low-end hardware, the application built with C is probably preferable. Consider:


That’s cplay, and according to htop, Python is taking up about 1.1 percent of the 512Mb I have in this machine, which means roughly 5Mb. (I wanted to use this script to get a closeup of how much each one is using specifically, but with both cplay and the script relying on Python, the results were occluded.)

Now compare that with its clone.


mcplay is hovering around 0.4 percent of the same available memory, which puts it at about 2Mb. In both cases, the space taken up by the ogg123 application, which does the real work for both frontends, is a meager 0.4-0.6Mb depending on the file and the workload.

The difference between 2Mb and 5Mb on modern machines is barely noticeable; most applications these days take up spaces 20 or 30 times those amounts, and no one bats an eye. On machines as old as this one though, or on machines that suffer from a severe memory handicap, those three megabytes can be critical.

And remember that in this instance, we’re only talking about an application that runs against the console, maintains a list of file names and feeds them to an outside application for playback. Imagine a Python application that is quite sizable, running on a graphical desktop, requiring an assortment of additional derivatives to function, and you can extrapolate beyond those meager three megabytes.

So I will nod in acceptance that yasen was right, and I should have taken into account the fact that program weight can be directly attributable to their programming language. If you are also plunking along on your Pentium machine and you have the choice between programs, for the sake of memory use it might behoove you to look for alternatives that are written in other languages. 🙂

5 thoughts on “Shaving megabytes: cplay and mcplay

  1. reacocard

    The memory use difference is usually worst on the low end of python programs, since the python interpreter itself has pretty substantial overhead. On my 64bit Arch system, a blank python shell (just type python at the prompt, no arguments) takes about 4.4MB, while cplay uses 6.8MB. So cplay itself it actually reasonably light, it’s just being dragged down by the inherent overhead in python. Larger-scale apps tend to have much less difference in memory use between those written in python and C, as the overhead of the interpreter becomes largely eclipsed. Not that that matters much for your use case. 🙂

  2. patrick


    A blank python shell is more than just the python interpreter. A more accurate example would be the memory usage of a (almost) blank python script.

  3. reacocard

    @patrick – ah, you are correct. A python file with nothing but input() in it (the smallest i could think of that would stay open for inspection) clocks in at about 3.6MB. Python would probably do slightly better on a 32 bit system though as it uses a lot of pointers.

    I also installed mcplay for comparison – its using a mere 1.5MB. Quite impressive.

  4. Pingback: Links 19/3/2010: Google’s TV Project, Turning 10, OSBC | Boycott Novell

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s