Big document, slow performance
I'm trying to use MultiMarkdown Composer to revise a 62,000 word book, and I'm finding responsiveness slow. There's a fraction-of-a-second lag when I strike a key. It's distracting. Is this something that you expect to improve in future updates? Is MM Composer designed for documents that large?
Regardless, I like MMC a lot.
Thanks!
Mitch Wagner
http://www.MitchWagner.com
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Fletcher on 30 May, 2013 01:32 PM
Mitch,
Thanks for purchasing Composer, and thanks for writing.
I periodically test Composer with a 45k word document, and then just tested with an 90k word document. It worked well, though the 90k word document hit the threshold where the first highlighting parse took too long, so syntax highlighting was disabled. The 45k word document worked well with syntax highlighting without any noticeable delay (to me, anyway). When I created a 60k document, it would sometimes trigger the "too long" failsafe, but not always. Typing was still responsive for me, though occasionally it would pause briefly --- presumably when something was happening like a file save.
That said, if you have the live preview turned on, and have it set to update with a 0 second delay, then there will be a delay every time the preview refreshes. I'm afraid that there is no way around a performance hit when you want to update a WebView with a document that long (Apple limits many function calls to a WebView to occur on the main thread, so Composer can't do that work in the background.)
I've included a lot of optimizations in Composer to allow it to work with long documents, though 62k words is getting long for any application.
Be sure you have the live preview function turned off if working on something that long. If you must have a live-ish preview, using Marked would effectively allow you to "background" the web refresh since it would happen in a different application. This might be a situation where using Marked would actually be better than using the built-in preview. Alternatively you can set Composer to update only when the document is saved, so you could manually control when a refresh occurs.
Be sure Composer has enough memory. Older versions of MultiMarkdown had some memory leaks, but these were fixed in 4.0, which is included in later versions of Composer. But processing a document that long requires a lot of memory. Activity Monitor can help you look into this.
Hide the HUD panels. When active, each of them has to monitor the textview and update when things change. This happens in the background, and should be a very minor performance hit, but in a longer document, if you are typing quickly I suppose it could add up. Hiding them will give you a slight performance boost.
Are there any other programs running that intercept typing inside of text views? I use TextExpander and it seems fine, but perhaps other programs could be interfering.
What sort of computer are you running this on? How much RAM? How many cores in your processor?
Many people working on works that large prefer to split the document up into separate files (e.g. 1 file per chapter, or something like that). mmd_merge is a utility for MMD that allows you to create a master index file so you can reconstruct the entire document to process with MMD. Composer supports that format, so when you want to see the whole document, you can stitch it back together. This may be another option if all else fails.
Hopefully this helps. In my tests, Composer works well with long documents, though you have to start being realistic about which features are enabled (e.g. live preview). Wherever possible, I designed it to prioritize typing responsiveness and to put everything else in the background. In any event, 60-90k word documents are getting up there, and splitting the document into smaller pieces would clearly improve things.
Fletcher
2 Posted by Mitch Wagner on 30 May, 2013 02:33 PM
Good tips, Fletcher. Thanks for them, and for the fast response.
I actually don't use preview; I'm comfortable working in bare Markdown and
previewing at the end. I keep the preview window hidden. Does that switch
it off, or do I also need to make a change in settings? Do I need to go
into Preferences -> General -> Update Preview Only When File Is Saved?
Mitch Wagner
Support Staff 3 Posted by Fletcher on 30 May, 2013 02:53 PM
If the preview is hidden, that's the same as off. No need to change preferences for this.
What sort of computer do you have? How much RAM?
Try running Activity Monitor while using Composer. Watching the CPU % can be instructive, and can tell you if any other processes are burning up cycles as well. The memory usage pie chart can help give you an idea as to how much memory is available.
F-
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
4 Posted by Mitch Wagner on 30 May, 2013 02:55 PM
I have a MacBook Pro Dec. 2010 with 8 GB RAM.
Mitch Wagner
Support Staff 5 Posted by Fletcher on 30 May, 2013 03:07 PM
That should be adequate.
I did some profiling, and it does look like one of the newer features I added is taking a few more CPU cycles than I thought. I should be able to improve performance a bit further.
Let me see what I can do.
Support Staff 6 Posted by Fletcher on 30 May, 2013 03:25 PM
I made a pretty simple change to one of the MultiMarkdown routines that dramatically improves performance when parsing while typing. It will be included in the next beta release (2.3b build (10)).
Whether this translates into more responsive typing on your machine will have to be tested.
F-
7 Posted by Mitch Wagner on 30 May, 2013 03:28 PM
Thanks! And I'll keep an eye on memory when I'm next working on the book.
I tried looking into mmd_merge -- is there simple documentation for its
installation and use with MMD Composer?
Mitch Wagner
8 Posted by Mitch Wagner on 30 May, 2013 03:31 PM
The problem was even worse with 2.2.1, which is the first time I noticed
it. With that version, MMD Composer not only slowed, but it crashed every
10 minutes or so when editing that big 62K-word document.
9 Posted by Mitch Wagner on 30 May, 2013 04:07 PM
Just as a point of interest: I'm not working on the book currently, but I noticed some slowdown in typing in my browser (not in MMC). So cranked up Activity Monitor, and sorted on the Real Mem column. And, lo, TweetDeck and Mailplane use a *ton* of memory. And I don't really need either; I can use web.tweetdeck.com and gmail.com in my browser. So I shut them both down and boy does my old MacBook Pro fly now!
We'll see how things go when I'm working on the book, which will be late in the day.
Thanks again!
Support Staff 10 Posted by Fletcher on 30 May, 2013 05:10 PM
Glad you were able to find a problem, if not *the* problem.
Let me know how things go with the better memory situation. And while OS X is pretty good at memory management, every once in a while it can be helpful to reboot and see whether that improves performance before a bunch of other apps get loaded.
In either case, thanks for prompting me to dig around so I could at least discover one tweak that can improve Composer's performance.
F-
--
Fletcher T. Penney
Manager, Founder
MultiMarkdown Software, LLC
[email blocked]
Support Staff 11 Posted by Fletcher on 30 May, 2013 05:22 PM
Also, instructions for mmd_merge are in the MMD user's guide:
http://fletcher.github.io/peg-multimarkdown/#howdoisplitamultimarkd...
F-
12 Posted by Mitch Wagner on 30 May, 2013 07:41 PM
Excellent. I'll follow the link. Thanks!
Fletcher closed this discussion on 30 May, 2013 09:05 PM.
Mitch Wagner re-opened this discussion on 30 May, 2013 10:58 PM
13 Posted by Mitch Wagner on 30 May, 2013 10:58 PM
Got it working. It's very cool. Thanks again!
Fletcher closed this discussion on 31 May, 2013 11:47 PM.