Quarter Life Crisis

The world according to Sven-S. Porst

« X.5 DevelopingMainShades of Red »

Lazy programming

557 words

There’s this technique in programming which people frequently refer to as doing things ‘lazily’. When using it, things are not all initialised when they start up but they are rather just loaded and initialised as required. That’s a cool and elegant concept both because it avoids initialising things superfluously and because - if implemented rigorously - it reduces the need for having some global and potentially hard to understand set-up to do.

These techniques are used a lot these days. From on-demand loading of libraries in applications, to the loading of helper applications (think launchd), to in-application details like menu validation. And in each of those places, things should become simpler to implement and easier to understand as a consequence.

The problem is that - quite frequently - the user experience suffers from that. And programmers simply ignore those problems because they ‘can’t do anything’ about them.

On a Mac you run into these problems all the time - at least if you keep the machine running for more than a day. Just think about the following situations:

Force Quit command in Dock menu

I am sure you can come up with plenty of additional examples of such unexpected and annoying waits which come from situations where something is supposed to work on the fly but takes ages to complete because the system considered it wise to swap the relevant code and data out of memory and tax using them with a long wait.

If the code in question weren’t as ‘lazy’, libraries might be readily loaded, menu items might not need to be validated by random code deep inside the application and trivial volume controls would appear immediately. Simply because they’d be loaded and remain loaded.

Perhaps a system with a lot of RAM (but how much exactly?) would solve these problems, but with the obscene and ever increasing memory consumption applications and frameworks have these days, I am not sure such setups will be feasible anytime soon. Rather, I keep thinking that system designers should make a bigger effort to find out which parts need to be immediately available at all times - and to make sure they are.

That may less elegant from a technical point of view than the ‘lazy’ way is but it would improve the performance and the more important perceived performance. I doubt that there can be excuses for menus not opening immediately. That’s simply a consequence of poor resource management and saying that convenient development is more important than convenient usage.

August 23, 2008, 17:16

Tagged as development, lazy, performance.


Comment by Jonathan: User icon

I think you’re getting confused over a number of things.

For a start I think you really talking about lazy loading. Lazy programming is something totally different, it involves delaying the processing of code till the results are actually needed.

However, the problems you are encountering don’t seem to be due to lazy loading at all rather the performance hit of paging in code from virtual memory*.

Memory is a finite resource and the memory manager does its best to keep everything running smoothly. Unfortunately it’s not a mind reader & doesn’t know when you’re going to switch back to the application you last used 6 hours ago.

Yes its a pain to have to wait a few seconds for memory to be swapped back from disk, but that’s the price we pay for being able to run more programs that we have the RAM for. The alternative is the OS throwing up ‘Out of memory’ messages and stopping you from opening any more applications.

Yes I would agree OS related functions such as volume control should be kept in memory at all times, but 3rd part applications, no.

August 24, 2008, 21:22

Comment by ssp: User icon

I think you’re getting confused over a number of things.

Yeah, probably the distinctions aren’t made as clearly as they should be.

I still think that these different issues are closely related. The ‘lazy implementation’ hurts particularly badly when virtual memory is used as, for example, the state of a menu item isn’t simply stored but has to be determined dynamically, thus requiring plenty of other code to be loaded. While it might be feasible to keep all the relevant data and code for drawing menus in memory in a less lazy implementation, I guess that it’d be hopeless (and probably crazy) to figure out all the code needed to validate menu items and keep that in memory.

What keeps irritating me is how bad OS X’s memory management is / has become. I don’t think I use the machine for significantly more than I did a few years ago. And I have tripled the amount of RAM in there (compared to my G4 Powerbook on X.3 or even increased the RAM by a factor of 30 compared to my last PowerMac, which could also do e-mail, TeX and web surfing) and yet I find that I’m seeing eternal swap waits much more frequently these days.

I really do wonder when I’ll have ‘enough’ RAM. Personally I quite liked the classic Mac OS system of simply not launching additional applications once the RAM was used. I had a good understanding of who’s using how much RAM back then and could easily adjust to that. All that while things remained responsive. But I guess all the Unixy ideas in OS X make it impossible to get such a system back.

Of course I see the advantage of not loading the print GUI unless it is needed from a memory footprint perspective. From a responsiveness perspective, though, I’d totally want it to be loaded at all times.

With Unixy memory management being a complete mystery, I wonder whether anybody could say how much RAM I’d need to keep everything running smoothly at all times. And if anybody can figure out how much RAM is actually wasted by sloppy programming.

August 25, 2008, 10:56

Add your comment

« X.5 DevelopingMainShades of Red »

Comments on




This page

Out & About

pinboard Links