Memory Exhaustion

I was particularly pleased at how well behaved WyCash was as it ran out of memory. I attribute it's good behavior to two simple rules...

Should the program begin to behave poorly, the user's natural tendency is to abandon inconsequential work by closing the windows that contain it. Memory is reclaimed and proper behavior resumes.

Primary data was stored in a database so that all windows could be closed and no primary data lost. What was lost was calculations based on retrieved records. Calculations were performed on demand. As a user scrolled a report, cells would be exposed that would then demand a calculation and cache the result to speed subsequent scrolling.

If many large reports were opened at once, memory could be exhausted as these calculations took place. The effect was to find cells that could not be filled and therefore remained blank. The program was trying to fill the cells, but as the calculations crashed for want of memory, an error handler caught the faults and, by our rule of not interpreting uninterpretable behavior, simply printed blanks. This poor performance would, as already mentioned, lead the user to discard some less important window and then return to find the blanks could now be filled with data.

This behavior has been judged extremely reasonable by non-technical users and is much preferred to hopeless dialogs that try to explain memory requirements. The behavior was the product of AbuseCase(s) considered elsewhere in the design. -- WardCunningham


I find this fascinating. Some questions:

Thanks - the ideas from this page will soon be in our commercial work and should be more widely known. Has this been published other than here? No, see HowToCiteWiki

See TechnicalFailure


EditText of this page (last edited May 24, 2005) or FindPage with title or text search