Tinderbox Forum

Suggestions on improving the response time?

Hi, there.
I’ve worked with TB 7.3.1 on High Sierra for months and with my TB file grows the response time of TB is continuously going sluggish.
I’m majorly working on a TB file with 140 Notes, 8517 words, zero agent and 133 links, which is, I think, pretty moderate size for TB to handle with. But the response time has become unbearable. Check this GIF:
Mar-11-2018 15-24-12
I’ve checked the thread Sluggish Response which talks about TB 7.0.1 and no solution (I’m sorry for that.)
In my case I found that TB responses ultra fast if there are no visible links on map, even with large amount of notes (200+). BUT it slows down once I create a link between them. Dragging a note with a link is a nightmare for me. And as the number of links grow, the map view just becomes unusable.
I’m curious to ask: What’s wrong with those links?
I’ve tried many methods, which I imagine, would improve the performance, like disabling shadow rendering of each notes, disabling text editor using Command-6 and assigning render pattern to “plain”, and none of them works, .
Any ideas/suggestions for this problem?
P.S. My machine is Macbook Pro early2015 with .7 GHz Intel Core i5 CPU and 8GB DDR3 RAM who is not ready to retire.
Thanks and best wishes,

That’s a rather small file. I would say your report is unusual, in my experience. Many users have files orders of magnitude larger, without errors.

However, the forum is not the place for diagnosing technical problems. I suggest sending your file to Eastgate support, which can look under the hood and evaluate it for you.

Yes, agreeing that this is way below the size at which Tinderbox has intrinsic scale problems. (I’m working in a file right now with more than a thousand notes, and more than 300,000 words.)

I don’t rely on links very much for my work and organization (versus colors and badges, attribute browsers, etc). So I don’t have huge-scale experience with very large numbers of links. So this again echoes the suggestion to send more info to Eastgate tech support. Good luck!

Ok I’ll forward my problem to Eastgate support. Thanks for your partition in this thread :blush:

The response time issue here is quite specific; dragging is slow in maps. The underlying cause is that, while the document is not very big, it’s all basically a single map, and one with a lot of links.

We’ll take a look at the details in play.

At what point do you recommend starting to use containers (which I assume will help with the “the document is basically a single map” issue)?

Everything depends on what you want to do. If a map is too large to use conveniently – if you spend a lot of time scrolling here and there – it’s good to think about containers.

Another thing that might help: try turning off Guides (View▸Guides). I’d be interested to know of cases where this turns out to help.

Happy to offer my old Afghanistan-COIN.tbx (516.0 KB) demo as a common reference. There are a lot of links on the Map:


Most of the above notes/links are on the TBX’s one main map:

Using my MBAir (spec**) external screen I can see some improvement with guides off.

** MBAir 2013 (13" + external 2011 Apple 27" screen), OS 10.12.6, 8MB RAM, 1.7 GHz Intel Core i7, Intel HD Graphics 5000 1536 MB.

FWIW, I’m pragmatic about what I can - or should - sensibly try on a single map. The above demo slightly breaks that. It arose from discussion of a blog post by @eastgate back in December 2009 (v5.0.0 just out!) here and in response to which I produced the first version if the above TBX.

I’ve tested that and the response time is the same when Guides are turned off.

Within this TBX file I can barely move. Every dragging causes ~2s response time and the map moves like flashcard.

FWIW, the file posted earlier had a large rule and export stuff in support of my (failed!) 2009 attempt to export the map to HTML. I’ve removed those rules and export related agents so the TBX is now essentially just the map elements; I have left guide ‘on’ (View menu) in the file: Afghanistan-COIN-ed.tbx (323.0 KB)

Any difference in performance between this file and the one I posted earlier reflects the under-the-hood activities of agents/rules. If unfamiliar, it’s worth taking a look at the Agents& Rules of the Tinderbox Inspector, as that gives some indication as the amount of work going on unseen in the background.