Sunday, April 24, 2005

ACCU 2005 - Small Memory Patterns

This talk provided 3 patterns from Charles Wier and James Noble's patterns book on programming on small memory machines. The talk covered the following patterns; Memory Limit, Packed Data and Fixed Allocation. They were pretty straightforward:

  • MemoryLimit - limit the allocation of memory and fail requests over that limit. The contacts list in a phone is an example of this. Charles also talked about other strategies such as FIFO and LIFO that are often used to decide whether to accept a request but do so by throwing away an existing allocation.
  • Packed Data - bit packing data.
  • Fixed Allocation - allocating all the memory you need for an operation ahead of time. For example, 911 systems in the US have memory pre-allocated so that a 911 call will not fail due to an out of memory error.

These techniques are commonplace and well recognised. The talk then went on to discuss techniques the audience have used. These ranged from using multiple heaps to avoid heap fragmentation through to using negotiation between devices to ensure there was capacity to honour a request and if not to tell the requestor to ask for less. The summary is a good place to look for outlines of the wide variety of approaches found in the book.

When considering the applicability of this book it's worth noting that small memory systems are not only systems with a small amount of memory (like a watch of a phone) but also systems with large numbers of users where each concurrent request ends up having a small amount of memory.

Whilst listening to this I wondered what a book on patterns for programming in 'low power' environments would look like. A book on low power environments would contain patterns that optimise on clock cycles, that discusses off-loading computation to hardware and would probably be very useful to JavaScript programmers developing in IE. I've been pondering IE JavaScript patterns for a while and it seems like many of the approaches found in embedded systems development[1] have and can be applied to the IE environment. The reason for this is two-fold:

  1. Performance. There are many activities in IE that have unexpected and significant performance hits. The developer spends a lot of time optimising JavaScript web applications in IE when there are reasonable quantities of data on screen.

  2. Memory. IE, its' DOM and associated clutter consumes a substantial amount of memory. Developers have to minimise memory consumption to get a web app to perform.



----
[1] Of course, programming embedded systems now is not dissimilar to programming non-embedded systems 15-20 years ago.