Maximum file size before performance drops


#1

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!


#2

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.


#3

@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.


#4

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.


#5

My file is not nearly as large, actually, at 1850 lines.


#6

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)


#7

Sure that might help (Activity Monitory)


#8

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


#9

In my case (Macbook Air 2011, macOS 10.12.6) the search performance on this file is also pretty good.


#10

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.


#11

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.


#12

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.


#13

@jessegrosjean I just PM’ed you a process sample obtained with Activity Monitor.


#14

@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.


#15

@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!


#16

@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.