The Blog that Noone Reads

I had a conversation about the merits of garbage collection vs. its tendency to cause complacency in developers in regards to memory management. My personal feeling is that as computers are getting faster and applications are getting more complicated, it’s important that we create reliable tools to allow our developers to accomplish more with less code. Garbage collection frees the developer up from worrying about the complicated internals of allocating and releasing memory. At the same time, we can’t believe that this means we don’t need to be careful about memory management. It just means we do so at a higher level. We still have to be wary of circular references and globals that never free from scope.

An article went up on Ajaxian today about memory fragmentation in FireFox. It discusses one of the more intricate challenges associated with manually managing memory. This is in contrast to another article I read recently describing garbage collection in Ruby. In this article, Why describes the garbage collection mechanism used by Ruby and how it affects the performance of code as well as providing useful tips for getting the most out of your application. Both of these articles describe performance issues cause by memory management systems. Read them both and decide which problem you’d rather have in your code.

Doing some profiling on an application, I discovered something interesting about how Hash works in prototype. See if you can tell the difference between these two operations:

// Method 1
$H({
    all: "are",
    your: "belong to", 
    base: "us"
}).toJSON();

// Method 2
Hash.toJSON({
    all: "are",
    your: "belong to", 
    base: "us"
});

The difference is subtle, but important. The first option turns your anonymous object into a Hash object by extending it’s prototype, then calls the instance method Hash#toJSON(). The second version calls a class method Hash::toJSON() and passes in the anonymous object. The resulting string is identical. The performance impact, however, is not. It turns out that the class method version is startlingly faster.

The reasoning for this has to do with how prototype handles enumeration of hashes. Internally, Hash#_each uses a “for in” loop to iterate over every property of the object. Because $H() adds a whole bunch of methods to the prototype of the object, the enumerator also has to check each property to make sure it’s not part of the prototype before passing it to the iterator method. What this boils down to is a whole bunch of extra effort for method one above as it first has to append a bunch of methods to the object, then iterate over them just moments before they’re forgotten without ever actually being used.

The moral of the story is, while the documentation may show an example using method 1, you should probably be using method 2.

TextMate is a brilliant text editor for OS X. It’s especially useful for people who write code or any form of markup. It’s user base is largely technical and the developer is aware of who their audience is. A recent blog post describes known issues with TextMate in Leopard. It describes the issues from an implementation detail level that’s very interesting, and very useful for a technical audience as well as providing helpful workarounds where available.

Allan does a great job communicating with his core audience. This is, I feel, a key factor in the creation of the community that’s such a valuable part of this splendid application.