I am experimenting with a “master” .taskpaper file, where I have merged all my previously separate files. It adds up to a bit less than 12,000 words, and unfortunately I am experiencing performance drops with it (UI lags). @jessegrosjean, I know you are working on core technology that should address performance issues, but meanwhile I’d like to ask whether the size of 12,000 words is one that you would expect to cause issues on a contemporary Macbook Pro. If not, then the problem lies somewhere in my own setup. Many thanks!
Hard to say, but I wouldn’t have thought that was a problem… seems like it should only be around 1000 lines and generally that should work. But performance problems are often very context sensitive. For example the outline structure of your file or even the character sets used in your file could all have an effect.
Is it possible to share the file? (or another one that exhibits the same problems). Also please example in a little more detail the exact performance slowdown that you see.
1 Like
@jessegrosjean, unfortunately I am not able to share the file because it contains sensitive data. I can confirm however that the magnitude of the problem seems roughly proportional to the length of the displayed (“focused-on”) content. Happy to provide Activity Monitor samples, if you think they could help. Thanks.
Same here.
I have one large file ( 5000+ lines) in which I store everything.
I observed only very recently that the perf drops hugely as a function of what is displayed, to the point that when nothing is filtered, I cannot even drag an item.
Hope that helps.
1 Like
My file is not nearly as large, actually, at 1850 lines.
For all of you, who wants to experiment with performance, here is the TOC of Britannica Propaedia formatted as TaskPaper document (lines: 8304; max. nesting level: 6):
propaedia.taskpaper (649.0 KB)
Sure that might help (Activity Monitory)
Thanks… I’m trying this file and performance seems pretty good. For example I search for “Transportation Technology” which is in the middle of the document and:
-
Type really fast, and it feels fast… text caret keeps up with typing even when I just press all keys as fast as I can.
-
Pressing Return also feels pretty fast
-
The one thing that is a bit slow is when you start at an inner time and Shift-Tab to unindent it all the way to root level… especially the last few levels. But I would expect that to be slow because it requires a some big updates to keep the tree model updated.
@macula @bmuyl how does that example file perform for you guys?
Also what macOS are you testing on? I’m on 10.12.6
In my case (Macbook Air 2011, macOS 10.12.6) the search performance on this file is also pretty good.
Just got sent a video showing performance problems on the demo file posted in this thread. Something’s definitely up, things that are instant on my computer with that file were taking 5+ seconds. One thing I noticed was that the stylesheet in the video wasn’t the default… if you are experiencing performance issues can you please try to switch back to default stylesheet (stylesheet with no text inside will do it) and see if that makes a difference.
I have a pretty fast computer, but @saf-dmitry reports above that performance is good on a Macbook Air 2011, so I think this means the problem must be due to some setting/context that I haven’t yet narrowed down.
Sorry for the lull. I can confirm that on my MBP the demo file posted above causes a hang (beachball) for several seconds, perhaps even over one minute(!)
Switching to a default stylesheet does not resolve the issue.
It might help to point out that the beachball does not appear when scrolling up/down with the touchpad but only when I try to move the cursor to a new position in the text. In fact, scrolling seems the only way to unlock the UI once the beachball has appeared.
Just to add another data point: I fiddled with the above file and didn’t notice any performance issues. I tried searching, changing indentation levels, moving branches around, and adding new lines. I’m on 2012 MBP, 10.12.6.
@jessegrosjean I just PM’ed you a process sample obtained with Activity Monitor.
@macula Thanks! It looks like all of the sample time is being spent in accessibilityHitTest which I wouldn’t have expected, and I don’t see that call even showing up on my own trace. I’ve been enabling accessibility tools, but so far haven’t had any luck reproducing the slowness that way.
@macula (and anyone else who’s seeing performance issues) Do you have an accessibility setting turned on? Or do you have a third party app that required you to enable accessibility settings for it’s function? Even if you can’t remember the details on either of those… can you try running TaskPaper in your guest user account and see if that solves the performance problem.
@jessegrosjean Thank you for looking into this. I may have found the culprit among the various apps that had requested Accessibility privileges (Preferences.app > Security & Privacy > Privacy > Accessibility).
It turns out that disabling Magnet.app, a window manager, practically resolves the issue. There is still a suspicion of lag, but small enough to be attributed to the complexity of the editor and stylesheets. (I think). Anyway, the app is usable again!
I will contact the developers of Magnet.app and report back if necessary. Thanks again!
1 Like
@jessegrosjean I must bump this one; it now seems safe to say that the UI lags that we (well, you) narrowed down to interference from Accessibility-enabled apps such as Magnet must be caused by a TaskPaper bug. I removed Magnet.app entirely from my system and replaced it with Moom, a similar app for window management, which likewise requires Accessibility privileges. It makes no difference, and the lag is the same in either case. This suggests that TaskPaper is the most likely culprit.
This is a very late response, but I think the latest preview release fixes this issue:
The accessibility API is very aggressive in the data it collects in some cases… in particular when you do a hit test in text area with accessibility API it scans the entire text storage for all link and file attachment attributes. This is an expensive operation in a large TaskPaper document. I couldn’t find any way to fix except to use private API to override that behavior and return nil for both link and attachment collections. Not pretty, but I “think” it will solve the problem for you.
@jessegrosjean thank you for working on this.
Unfortunately the improvement is questionable on my system. There is indeed a measurable improvement but TaskPaper is still barely usable, with delays of up to 0.3 or so between keystroke and response.
Also, a curious side-effect of the fix is that disabling the accessibility app altogether does not substantially decrease the lag, as it did before the fix.
I think initially the problem was mostly related to positing the cursor with the mouse? But now it seems like the problem is just with standard text input?
If that’s the case can you send me another sample taken with Activity Monitor? And can you use the “propaedia.taskpaper” file posted above, and note where you are typing in that file when you take the sample. (this way I can try to reproduce on my computer). As far as typing, you can just type random characters as fast as you can for a few seconds.
For me the performance is still instant in the “propaedia.taskpaper” file when I type. I’ve also installed and enabled the Magnet app, things still seem fast.
@jessegrosjean the problem now seems “magically” resolved. I don’t know what might have changed the system state, possibly some cache was flushed in the background or something, but in any case things are now working as they should. Very happy to behold! Thanks again, and apologies for the false alarm.
1 Like