One problem I've been having with my note-taking app is that it grows sluggish over time. This is an unavoidable tension: simple programs tend to be inefficient, and optimizations tend to make programs less approachable. Meditating on helped me speed things up significantly -- by reading data redundantly from disk. In the process I realized that garbage collection is missold as "automatic memory management". All memory management is manual. There's no substitute for thinking about your program's memory footprint. More details in 🧵

My note-taking app consists of multiple text-editor widgets arranged on a 2D surface. I tend to add notes to the surface but leave them lying around. Over a month or so of use things would get sluggish and I'd have to start closing notes. Watching the Mike Acton talk got me to focus on this, and on ways to improve its memory footprint without complicating things too much. Lua doesn't have very good profiling tools, so I can't easily see where the bottleneck is. But I eventually hit upon a plan that worked very well: when a text editor widget goes out of view, just blow away the data backing it. When it comes back into view, read it from file. That's it! It took me a while to convince myself that this would be a net win. I'm replacing reads from memory with reads from disk. The key realization: it's a trickle of reads to disk replacing an unbounded amount of stuff that's just always hanging around in memory. I think this is a data-oriented solution in the footsteps of Mike Acton even though it didn't delete any fields from structs, or switch to struct of arrays or anything like that. Lua doesn't really give me control over how cache lines are packed or avoiding pointer indirection, but I was following the key principle Mike Acton articulated: you always have to manage your caches. Emphasis on the "you". No tool can do this. This experience has changed how I think of garbage collection. I no longer think of it as "automated memory management". In my new worldview memory management is always manual. GC merely allows you to reduce the ceremony of deallocation. Where in C++ I had to maintain a bunch of destructors and explictly call delete, with a GC I can just assign a variable to nil to blow away everything inside it. This seems like a powerful insight. GC isn't magic. It's still the programmer's responsibility to point out what can be reclaimed. This experience shouldn't be so surprising. I've been around enough to know the theory. I've heard the war stories about how Google ran successive generations of its search frontend off disk, then memory, then disk again. I think the surprise stems from seeing this dynamic in action in a tiny program with a memory footprint of 10-20MB. There's still plenty of room to trash your processor's cache (0.5MB in level 1, 8MB in level 3)

(N.B. Whether or not memory was the cause of the slowdown, the observation that GC is just one strategy for deallocation is correct.)

(I just noticed the video at the top of this thread has somehow gotten deleted. Fat finger? Slack shredders approaching? Anyways, you can see it at https://spectra.video/w/051fef50-a121-40c0-bf3c-ee0730fb4a07)