Relatively hot-on-the-heels of the previous release, MarsEdit 3.1.4, fixes some major memory performance issues and includes some fixes that streamline integration between Tumblr photo posts and the media manager.

Major Memory Meltdown

I have always been pretty proud of my ability to manage memory usage in my code. In addition to using good programming habits, I periodically run Apple’s memory leak-detection tools, and the clang static analyzer. These tools do a great job of finding accidental memory management errors. But as I discovered, they are not enough.

For months I have received anecdotal feedback that MarsEdit is using more RAM than it should. But I couldn’t find any evidence of wrong-doing on my part, so I committed a major mistake: I just assumed it was normal. MarsEdit uses a lot of Apple’s frameworks, including WebKit, which is so big and expansive, I assumed there was something about the degree of WebKit I use in MarsEdit that explained the large amount of memory consumption.

Wrong! I was inspired by a recent one-two punch of feedback, combined with a recent blog post I had read, to dig deeper.

Twitter user @Fletcher_Chris was exceedingly polite when he asked if MarsEdit’s 200+ MB memory usage was “normal.” Ugh! Normal? I don’t know? I think so? Not knowing about why your software does what it does is a major alarm bell.

Then my friend John Gruber wrote to let me know that not only is he noticing major RAM consumption, but that it’s something that has bothered him for some time now. A recurring, nagging issue, noticed by somebody who is technically competent enough to know a real issue from a false one. I have a problem on my hands.

It was lucky timing that my friend Bill Bumgarner recently published an article on the very subject of hard-to diagnose memory leaks. I had actually read this article, enjoyed it, and blithely assumed it didn’t apply to any of my current software challenges.

It turns out that MarsEdit was in fact suffering from exactly this kind of leak: one that the brilliant leak-targeting tools from Apple are not able to detect. For a variety of reasons mainly involving retain cycles, I was neglecting to clean up after a major part of the MarsEdit post editor’s user interface, which means that every newly created and closed document would leak hundreds of KB of RAM.

Mea fricken culpa. Fixed in 3.1.4.

Tumblr Photo Posts

Tumblr has been a major challenge for MarsEdit because of the degree to which it doesn’t follow the usual paradigm for media management. This means in a nutshell that things you can do with almost every other blog system are not possible in Tumblr, making the user-interface a little clunkier to handle. In particular:

1. Tumblr does not allow direct file uploads. Even though their web-based UI allows you to upload an image for direct insertion into a post, this is not something they have exposed for remote clients such as MarsEdit.
2. Tumblr supports the notion of a “Photo” type of post, but it takes at-most one single photo. Usually MarsEdit is happy to add as many photos as you like to a post, but with Tumblr it has to be limited to one, and requires that the post type be switched to photo.

In MarsEdit 3.1.4, I take baby steps towards improving the situation when users do want to publish photos to a Tumblr blog. First, the per-blog “image constraints” settings are now applied to Photo posts on a Tumblr blog. So if you’ve got it set to limit posts to no more the 400×400 pixels, it will apply to any photo you drag in to Tumblr’s photo well.

I also streamlined the experience when choosing a photo from the Media Manager for a Tumblr-style post. Not only will the image constraints selected in the Media Manager be applied to the photo, but for example selecting and inserting a photo will automatically set the photo for the open Tumblr post document, or create a new post if one is not already open. This should make the photo-blogging experience on Tumblr a lot smoother.

A Curious Lack of Crash Reports

Since MarsEdit 3.0 was released, I have included a crash reporter mechanism that will automatically notice when MarsEdit quits for any unexpected reason, and offer to let the user send me a crash log plus any additional information they choose. This has been a great tool for measuring the number of harder-to-find bugs that remain in MarsEdit, and for zeroing in on and fixing some of them.

Luckily, the flow of crash reports is a relative trickle, compared to the number of users running MarsEdit on a daily basis. But after MarsEdit 3.1.3, the crash reports all but dried up! Was I really so brilliant as to accidentally fix any remaining bugs in the application? 3.1.3 forever!

No, what actually happened was I was brilliant enough to break the crash reporter in 3.1.3, so that it would fail to present the dialog to users offering to send in the report. Crashes were still happening, I’m sure, but I wasn’t hearing about them. Now fixed in 3.1.4, and I’m anxious to get back to monitoring the pulse of MarsEdit stability with this great feature.

This entry was posted to Debugging, MarsEdit, Programming. Comments are closed. Thanks for reading!