macOS Program size

[mysterytramp]

We have acres of RAM at our disposal. You can get a terabyte of storage for under $200. So maybe this isn't such a big deal, but I d/l'd a simple little to-do manager the other day that clocks in at 45 megabytes. My first hard drive was less than half that!

The program was written in Python. Is this par for the course or bad programming?

Or has the idea of tight code been forgotten because resources are so cheap now?

mt

 

[beg_ne]

I guess it depends, a lot of Apple programs in my Applications directories are larger than 45MB.

However I am using Things as my To-Do list program and it clocks in at under 6 MB.

 

[HiRez]

Are you talking about resident RAM size or storage size? There's no doubt that apps have ballooned in both in recent years, and Cocoa apps are insanely hungry for RAM. A newly-launched Safari or Firefox with a single page open eats about 60 MB of RAM, Mail about 50 MB. I think all of what you mention are true. RAM and hard drive space are cheap and plentiful nowadays, so Apple and developers simply don't worry about trying to optimize the nuts out of every little piece of code any more. Interfaces have gotten more graphical and media-rich, and that requires more resources. As do higher-level internals such as Core Data, Cocoa Bindings, Notifications, etc..

But, for most people the hard drive space consumed by applications will be dwarfed by media nowadays anyway, and most machines come with 2 GB RAM (with a 3-4 GB upgrade being not very costly). Overall I think it's a good thing because while there is definitely some wasted resources, we're generally getting a better user experience.

 

[savar]

We have acres of RAM at our disposal. You can get a terabyte of storage for under $200. So maybe this isn't such a big deal, but I d/l'd a simple little to-do manager the other day that clocks in at 45 megabytes. My first hard drive was less than half that!

The program was written in Python. Is this par for the course or bad programming?

Or has the idea of tight code been forgotten because resources are so cheap now?

mt

Hard to answer your first question, but you are generally correct on the 2nd point.

Tight code is still good, but you have to realize that instead of running close to the metal, these programs are running on top of stacks of software layers. These layers (such as the OS, frameworks, runtimes, etc.) provide lots of services that increase the quality of the end-user application (for example, doing most of the memory management).

Especially for small apps, there is little incentive to program close to the metal. You can write a todo list in python in an afternoon, whereas writing it in C would take several days -- and would be fraught with the peril of bugs, inconsistent interfaces, etc.

The tradeoff is the cost of the developer's time versus the cost of the user's time. Since the user doesn't perceive any wasted time, that person's cost is negligible and the only real cost to consider is the developers.

The other thing you should keep in mind is that modern apps contain far more functionality and polish than they used to. A big part of the 45 MB is for graphics used in the interface, different localizations (languages), code compiled for different processors, etc.

 

[savar]

Are you talking about resident RAM size or storage size? There's no doubt that apps have ballooned in both in recent years, and Cocoa apps are insanely hungry for RAM. A newly-launched Safari or Firefox with a single page open eats about 60 MB of RAM, Mail about 50 MB. I think all of what you mention are true. RAM and hard drive space are cheap and plentiful nowadays, so Apple and developers simply don't worry about trying to optimize the nuts out of every little piece of code any more.

To take your example of Safari, that's a great example of the tradeoffs between CPU time and memory.

Although both have fallen in cost dramatically, CPU is still relatively much more expensive than memory, so developers (especially at Apple) use lots of caching to exploit this tradeoff: specifically, they store large amounts of pre-computed material in memory so that the information doesn't need to be calculated again.

In the example of Safari, it's storing a large, hi-resolution rendering of the web page you're looking at, and of the web pages you previously looked at. The reason for this is that when you scroll up and down, or click forward and backward, instead of re-calculating all of the [very complex] visual elements, it just grabs the rendering from memory.

 

[mysterytramp]

Are you talking about resident RAM size or storage size?

I was talking about storage. It uses 47 megs of RAM. Even if resources are cheap, it just doesn't seem like you're getting value from memory and hard disk space it's consuming.

Apple apps aren't much better (iPhoto 06 uses a whopping 550 megs of storage and needs 85 megs of RAM. But I feel like this is RAM/storage well spent because of what iPhoto does. A little to-do list ought to use less space.

BTW, I found a little calculator called "Calcul Engine." 172K on my hard drive (not a typo) and 15 megs of RAM. Apple's Calculator has eaten up 7.4 megs of my hard drive and needs 19 megs of RAM.

Savar -- You make good points. I asked about Python because what little I know about the language intrigues me. But if the little bits of software I'm capable of clog up my hard drive, I might keep it at a distance.

mt

 

[Catfish_Man]

47MB of ram used for a todolist app seems unusual. It's easy to hog memory, but not THAT easy. How are you measuring ram usage, btw? RPRVT in top is generally the number to look at.

 

[mysterytramp]

Memory Usage Getter.

 

[robbieduncan]

I was talking about storage. It uses 47 megs of RAM.

These two statements make no sense. Storage is not RAM. Storage is the amount of space it takes on the hard drive. Your hard drive and your RAM are two totally different things.

 

[mysterytramp]

These two statements make no sense. Storage is not RAM. Storage is the amount of space it takes on the hard drive. Your hard drive and your RAM are two totally different things.

It makes perfect sense if you follow the thread.

MT: ... a simple little to-do manager the other day that clocks in at 45 megabytes. My first hard drive was less than half that!

HiRez: Are you talking about resident RAM size or storage size?

MT: I was talking about storage. It uses 47 megs of RAM.

The program consumes 45 megabytes on my hard drive. It consumes 47 megabytes of RAM.

 

[lee1210]

It makes perfect sense if you follow the thread.

MT: ... a simple little to-do manager the other day that clocks in at 45 megabytes. My first hard drive was less than half that!

HiRez: Are you talking about resident RAM size or storage size?

MT: I was talking about storage. It uses 47 megs of RAM.

The program consumes 45 megabytes on my hard drive. It consumes 47 megabytes of RAM.

In robbieduncan's defense, this was ambiguous. 45MB may have just been an approximation.

In any event, did you see if the 47MB is just the private size? If it includes shared size, that will cover all sorts of libraries, cocoa, python, etc. If your program is the only one on the system using these, that's undesirable. Otherwise, those are really only in memory once for everyone to share, so it's not so serious. The disk space is surprising. Is this an application package? If so, have you looked inside to see where the greatest usage is? Is it actually in the .py script (seems unlikely)? If not, where is it?

-Lee

 

[gnasher729]

We have acres of RAM at our disposal. You can get a terabyte of storage for under $200. So maybe this isn't such a big deal, but I d/l'd a simple little to-do manager the other day that clocks in at 45 megabytes. My first hard drive was less than half that!

Apart from the fact that the program size annoys you, does it affect the operation of your computer in any way?

 

[lee1210]

Since a number of people seem curious, what's the app? I'm sure we could pick it apart and see what's going on. Did it come from a reliable source?

-Lee

 

[mysterytramp]

For the record, I left its name out because I didn't want anyone to construe that I was criticizing it or the people who programmed it. I was just curious whether this was an artifact of Python programming generally.

Here's the app. It's called Task Coach. A - it's free (always a big plus in my book). B - it's open source. I didn't know it was Python until I d/l'd it and gave it a spin.

 

[lee1210]

Just grabbed it, here's a breakdown of the package contents:
Frameworks 22.9
-libwx_macud-2.8.0.dylib 19.8MB
-libwx_macud_gizmos-2.8.0.dylib 496KB
-Python.framework 2.6MB
--Versions
---2.5
----Python 2.6MB
----Resources 8KB
MacOS 124KB
Resources 22MB
-lib 22MB
--python2.5
---lib-dynload 19.3MB
---site-packages.zip 2.6MB

Whew, OK.

So where's the bulk of the usage? Providing the whole python runtime (Resources->lib->python2.5). This shouldn't be necessary in later versions of Mac OS, but this allows this app to run on older versions that don't have python available.

The other big thing is libwx_macud-2.8.0.dylib. This is wxPython, which is a python implementation of the wxWidgets framework for windowing. With the Python to Cocoa bridge introduced in 10.5, something like this should not be necessary, since standard .nib/.xib files can be used for the GUI.

Now for the ram, from top output:

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
 1672 TaskCoach    0.0%  0:05.17   1    82   463  25.5M  40.2M  50.7M   309M

So the private memory is 25MB. Not great, but only about half of the total due to the shared library (likely libwx_macud-2.8.0.dylib, which is unlikely to be used by much else, so really this process is the only one benefitting). The developer chose to use a library to provide windowing, at the cost of some memory. The python runtime is also likely to be using most of that private memory.

They also packaged the universal binary version of these files. That's fine, but it does cost on disk space. Using xslimmer i got it down to 30MB of diskspace, but this doesn't help in memory usage during runtime.

Essentially this app was written using a very modern language, with existing frameworks that were not native to the platform. Because of this, there is a cost to the end users. Like I said, this could be mitigated in a few ways. If you have python 2.5 installed, you could softlink /lib/python2.5 from resources to your local copy, and get back 22MB of diskspace. That, along with xslimmer, would probably get you down to about 11MB of diskspace, and that would still be mostly wxWidgets.

The python scripts themselves are 8.5KB. The rest is all overhead for making sure you don't have to do any legwork to run the app, or limit you to later versions of OS X, etc.

Not sure if you were really wanting it picked apart, but there you go.

-Lee

 

[Sayer]

Localization can eat up disk space especially in Apple apps. I always delete all languages except English from Apple apps on new installs of Mac OS X (or updated apps).

I don't plan on learning Chinese or Swedish any time soon, so they all go.

Frameworks can take up a lot of space since they include *all* functionality even if the app uses only a portion of the features available (static linking FTW!).

Developers can build their frameworks in such a way that they only include the basic functionality the particular apps needs, if the developer is making their own frameworks (from open source or otherwise external sources to the app).

A lot of the bulk of iPhoto these days comes from all the image processing, book and print creation and device support needed to make it drop-dead simple to use.

If you object to a 45 meg. task organizer, find a smaller one.

 

[Catfish_Man]

Nice analysis, lee1210

 

[mysterytramp]

Not sure if you were really wanting it picked apart, but there you go.

Actually, Lee, this is more than I was looking for. Catfish is right, this was a great analysis.

Now you should take iPhoto apart and show why it doesn't need to be 500 megabytes! :

mt

 

[lee1210]

I won't tear it apart, but basically it looks like the majority of iPhoto's usage is in Contents/Resources/Themes (about 380MB). I guess these are book themes? I'm not really sure. my copy has each theme localized as well, which seems to contributed about 100MB. That, along with it being a universal app, adds up. Significantly, it seems.

It is unlikely to make a huge difference, but Xslimmer can help eliminate universal code, so you aren't carrying around the extra PPC code (or Intel code if you are on PPC) that you'll never use, and it tries to eliminate localization also.

http://www.xslimmer.com/
Problem: It's non-free. I'm not that worried about these sorts of things, so I haven't registered it, but thought i should check out what kind of difference it could make.

As an aside, you can do much of this on your own in the future if you'd like by using "Show Package Contents" from the contextual menu of any application package. A hint: the usage will hardly ever be in the actual executable code.

All of this says nothing of run-time RAM usage. This will likely be much higher "nowadays" compared to in the past, due to large "stacks" of supporting libraries, frameworks, etc. that will get loaded. Especially with a language that's distributed as source and has a runtime, you have to load the whole runtime, which is "heavier" than most natively compiled applications.

-Lee