Why *did* Composer use so much memory after it's been open for a while?

This has been fixed. See below.

Short version: When Composer runs for extended periods of time with the preview pane active, it will require increasing amounts of memory. While working on a fix, the temporary "band-aid" is simply to quit and restart the application. If you don't really use the preview pane, turning it off will greatly improve this.

Longer version: MultiMarkdown itself, not the Composer application, has several memory leaks. These cause a negligible effect when run from the command-line on modern operating systems since the OS cleans up the memory when MMD quits.

When using the preview pane in Composer, however, MMD is potentially called after every key stroke and those memory leaks can add up over time.

We're working on trying to fix the memory leaks, but it's a tricky problem since MMD is written in C which doesn't have all the really useful memory management features that modern Objective-C offers (which is why Composer itself doesn't really suffer from any meaningful memory leaks that I've found yet.) Unfortunately, to really fix this may require rewriting much of (if not all of) MMD --- this will be something that takes time, and the end result of all that effort will be something that most people never notice....

Thank you for your understanding.

Fletcher T. Penney
MultiMarkdown Software, LLC

4/8/13 -- Update: Tracked down a few of the offenders over the weekend, but still more to go.

4/14/13 -- Update: Had a breakthrough idea earlier in week and figured out a way to rewrite MultiMarkdown itself to be cleaner. Making better progress than expected. Currently it passes 10 of the 23 basic Markdown tests (and a bunch of those fail because it doesn't support links by reference yet.) Once I get HTML support finished, adding LaTeX, FODT, OPML will be relatively easy as the hard work will have been done. Then I need to add a few features to get the same code to serve dual purpose as converter and syntax highlighter. This will make it easier to maintain moving forward. Once I get this done, the memory leaks should go away in Composer, and it should be much more stable as it will avoid some of the impossible to reproduce crashes as the new code is written to be entirely thread-safe.

4/17/13 -- Update: MMD 4.0a now passes all of the basic Markdown tests (except for the 1 that peg-markdown and peg-multimarkdown "fail"). It passes 14/26 of the MultiMarkdown tests, and 18/26 of the Compatibility Mode tests. A few core feature additions should allow it to pass the majority of those missing tests. The code is still memory leak free in my testing, which should dramatically help Composer!

4/26/13 -- Update: MMD 4.0b is now public. It passes all but 1 test that it should pass (HTML, LaTeX, ODF, and OPML). Still no memory leaks that have been identified. Next step is to start integrating 4.0 instead of 3.7 inside of Composer, which should make Composer much more stable. In the meantime, I hope to get some more feedback on 4.0 from other users to make sure there aren't any hidden regressions that will cause trouble with Composer. Looking forward to getting this out there!

4/30/13 --- Update: I have integrated MMD 4.0 in Composer for document conversion (e.g. HTML previews, export features) and it's working great so far. I have also started using the new code for syntax highlighting and have maybe 20% of that working.

5/1/13 --- 2.2b is out and uses the new code. Under general usage in my test, no leaks!