Tinderbox Forum

What are best practices to debug slow Tinderbox file performance?

My Tinderbox file has about 50MB with a few images and about 20k notes. I use Tinderbox 8.0.1. Working e.g. on outlines is slow. Opening opening notes in the tree hieracrhy may take up to 10 seconds (with spinning wheel or nothing happening). It really effects my productivity and I have hoped 8.1 has a faster performance. I admit it is a file with somr historical experiments, but all agents are turned off.

What are best practices to debug such a file for faster performance? What makes the file so slow?

  • Turn off all agents (any trick I can see if any agent is still active?)
  • Reduce protptypes?
  • Remove images?
  • …

Thanks a lot in advance!

Send a copy of the file to support (tinderbox@eastgate.com) and we’ll figure out what’s taking so long.

20,000 notes is a fairly big Tinderbox file! Offhand, my guess is that you’d see better performance in outline if you avoid having more than a few hundred notes at any one level of the outline, and don’t expand containers you don’t need right now.

Agents and Prototypes are very unlikely to be an issue for this. Big images can slow down loading and saving, but that’s not the problem you’re discussing here.

@eastgate thanks a lot for the quick reply and your tipps. Sorry, I cannot share such a fle with all my personal notes. Maybe I should write a script changing all content with arbitray letters. :wink: But thank you for the offer.

OK – that happens.

How many notes are there in the outline you’re working with — not counting notes hidden inside collapsed containers?

cc @eastgate
That’s an interesting issue – I know that OmniGroup for example, supplies a button for creating a scrambled-text duplicate in their problem-reporting frameworks – probably far from trivial to write, and might be slowish with a huge database, but could be very helpful in such cases …

1 Like

Probably not as common a need as it might appear.

1 Like

Wouldn’t it be fairly easy for a user to make a duplicate of the document and then run a ready-made script that goes through and scrambles, say, the value in the $Text attribute of notes? Or, perhaps easier, just set the value of $Text to some arbitrary text?

It does perform faster when I have less notes open. I have normally two windows open to faster navigate in my notes. But I guess that makes it even slower. But I believe my database is flawed. When I change from my outline view to chart view it takes about 2 minutes (spinning wheel). What do you recommend to do? Shall I better split up my notes in different files?

  1. A chart view of the entire document has got to lay out 20,000 items, which can be a lot.
  2. If you don’t need to have everything in one document, smaller and more focused documents will help.
  3. Even if you do benefit from having everything in one document, smaller and more focused views will help. If you only need a chart or treemap of one section of the document, that will require a fraction of the effort needed to layout the entire document.
  4. If other people have performance issues and can share their document, we can often identify precisely what the problem is, and we can often remove the bottleneck.

Thanks a lot @eastgate. Working in a tab view way makes the outline view perform much faster. I want to keep it as one large file to use links. And working with different tabs is sufficient.

Do you use Display Expressions or Hover Expressions. If you do, avoid having lots of notes all running complex DE/HE on the fly. The simple guard for this is to use a rule or edict to pre-calculate the DE/HE output, storing it as a string. The DE or HE then simply displays that string - which the calculation happening on the fly.

Outline & sorted containers. As some of my documents have grown I find I tend to turn of sorting except when actually needed (which generally isn’t often). It’s one less bit of work for the view to have to figure out when working with big/long outlines.

I agree with these tips from @mwra, and over the years I’ve found big speed differences with modest changes like those he suggests:

  • In outline views, I will often keep “containers” collapsed (ie, not displaying their sub items) unless I am actually working with those items. That way the program doesn’t have to be constantly figuring out how to display all those component items.

  • In containers with a lot of sub-items, I have found it valuable, as Mark A says, to leave Sort turned off, and turn it on only episodically when I need to re-arrange things. Eg: I had one enormous container with more than 1000 items in it. I had set the container to do a two-level Sort, by subject and by date. That made the file seem sluggish. I switched that container to “Don’t Sort,” which left the items in their already sorted order. Whenever I added enough new items to have a possible effect on ordering, I would sort it once again – and then turn sorting off. The point is, there was no need to have it running constantly on a usually static list.

  • Have learned through experience to agree with Mark A on avoiding Display Expressions that have to be constantly re-calculated as well. (If you store those values in a string, as he suggested, it’s much lighter lifting.)

  • The Attribute Browser is the equivalent to the Industrial Revolution, in ramping up TB ease-of-use and power. Get to know it and rely on it, if you don’t already. Considering how much work it does, it’s surprisingly quick and responsive. A long discussion of its virtues and techniques is here: How to use the Attribute Browser

1 Like

Heartily agree. With a large screen (e.g. 20+") AB view with column view enabled turns it all the way up to 11.

Thanks for all the tipps. For the outline it works now better if I keep containers closed and work more in tabs. But I wish I could use the Atttribute Browser (AB) efficiently. Even if I am in a subtree with e.g. 100 notes and then switch to AB then it takes about 30 seconds to load. Why is it always loading all notes? Almost every click in the AB leads to a spinning wheel. I guess I still have some flaws in my file. Anyhow not really complaining as most works great and I love the new hyperbolic view.

The default scope of the attribute browser is the entire document. So, if you have thousands of notes, each note needs to be examined and classified in order to put it in the correct category.

That’s one reason for attribute browser queries.

2 posts were split to a new topic: Debugging performance issues