Crashing and slow

I just purchased version 9 and was trying to update my main file. I have been running into a lot of crashing and whirling ball of slowness. My first thought is that I have something confusing in my agents that is causing things to slow down because in earlier versions this file was quite fast. Is there something I can check?
My agents seem to be working and updating OK, but I must have added something that is slowing it down and causing it to crash. I am not sure where else to start looking…Suggestions??

Hi @Dthomp310 - personally I haven’t faced any issues opening old projects with Tinderbox 9; it’s been working great for me in that regard.
Although you haven’t mentioned the last version under which your project was working smoothly, your computer processor power, or the project file’s general structure (# of Notes, Agents, Edicts, etc) - here are some things I would try.

Make copies of the file first! Then try:

  • delete all Agents
  • strip out everything but the actual Notes. Check your Notes for things like $DisplayExpression Attributes - particularly those that derive values from scanning or performing calculations on your notes.
  • Edicts can also be stripped out.

Then, check for performance improvements.

Some “Stage 2” tricks I’d attempt (on separate copies of your file, and not necessarily sequentially):

  • Copy and paste all the notes into a fresh blank Tinderbox 9 project file.
  • Delete one half of the notes, or the other half, and keep deleting until you find one or more Notes that are causing slowdowns/crashes.

When all else fails - your last but best option is to forward it to @eastgate via email for analysis, if there is an incompatibility of some kind he will find it.

Good luck.

@Dthomp310, sorry to hear that. Like @archurhh I’ve had not such problems, but a crash is a crash and that’s where you’re struck. His suggestions make eminent sense.

The Agents & Rules Inspector (see here) can give you an indications as to how much automation is running in your file.

Another cause of upset can be content imported /pasted into Tinderbox. Did the slowdown start on first opening in v9, or did you add additional data. If the latter, I’d look at those.

I’m aware that @eastgate is on leave right now so atypically way from most instant comms. If stuck, by all mean PM me an I’d happy to take a look (in my role as volunteer admin & community support) at your file, in confidence of course, especially if you can’t get the file to work at all.

Anyway, hopefully Art’s sensible suggestions will help you get to the source of the problem.

Another factor that I was wondering about is that I have been storing my files on Dropbox. When I tried to save a file that I had opened from Dropbox, I got an error message stating that it was not a permanent storage. I had moved my Tinderbox files because they got large (100+mb)
I have also pasted content from other Tinderbox files. That may be another culprit.

Saving to Dropbox will not cause problems, and will not generate a message that this its not a permanent storage.

Saving to a read-only disk image, will do that.

What sort of content are you pasting? Just text, or images/highly styled text/etc.?

I had added a lot of images for my art inventory. I have since watched Michael Beck’s tutorial on efficiently storing images and will have to change it all.

I have taken out all the agents and have started from scratch. I had 10 agents with 558 rules. I brought it down to 5 agents and 252 rules. It is working a lot more smoothly with no errors. I will build slowly.

Glad to hear that. I feel for the developer here. Rules and agents are easy, yay!, but at scale start to bite. But point that out too early in the process and some won’t want to start using them. But, you’ve ended up here at the forum which is good as it is—I trust—a safe place to discuss this. Most of the advice you’ll get is from people who’ve experienced the same problem. Key point: you’ve done nothing wrong!

Agents:

  • Remember you can turn them ‘off’ (see more on this). The aliases remain, and actions run on them continue, but that agent is no longer running that query and removing/creating aliases every agent update cycle.

Rules vs edits vs. Stamps

  • Rules (and agent actions) basically run at full speed. In a small doc with few notes, the effect is moot. Scale up and if you’ve 10s of rules running to check for something you might do only occasionally.

    • Rules (and edicts) run on originals and any aliases whether they be inside agents or manually created aliases. If a note has a rule and has 7 aliases in different agents (even if agents are ‘off’), then every rule cycle the rule fires 8 times, not once as you might assume.
  • Edicts are essentially rules—in terms of scope—but ones which run very occasionally. It is akin to an agent set to a low priority (q.v. above). There is no priority control for edicts. They are designed for background work, i.e housekeeping tasks that need to run occasionally but not often enough to have impact in the more pressing rules. edicts can still be run, manually, on demand if you know that ‘now’ is when you need it to run.

  • Stamps, from my experience are a useful as a project matures. They run immediately and once only per button press on the Stamps Inspector on the selected note(s). So, how do stamps help?

    • They can act as an on-demand rule/edict. In other words the periodicity with “when I need to run it”.
    • They only run from manual triggering. So they don’t run in the background adding to background activity.
  • Stamps are great for testing. That complex [sic] rule you are writing? Perhaps try it first as a stamp. Once the code works, that’s a good time to implement the code as a rule or stamp (paying heed to the points above).

Sadly, Tinderbox can’t tell you, other than by running less speedily than previously that the above effects are biting. The Agents & Rules tab of the Tinderbox Inspector is a good place to get a feel for how much background activity is going on.

As regards images: they can bloat the file size of the Tinderbox but other than increasing the memory load of the running Tinderbox app (which affects low powered Macs more than top-flight ones) they shouldn’t affect general performance once open. That said, the more $Text content (text or embedded images) the longer any single note may take to load in the text pane.

Though Tinderbox happily accepts embedded images in $Text, I don’t think (my [sic] take) it was never a core need/intent. Back in 2000 when the app was originally envisaged, text was the main content of $Text. I see you’ve found @beck’s comments on image use which I think cover the issue well. Ask yourself, are you adding an image as a means of ‘just’ clipping interesting stuff or because it is central to the point of that note? If the former, you might well do to back out the image into the OS or a tool like DEVONthink and link to it (don’t overlook text Preview mode - a sort of non-exported export view).

I hope that helps, and don’t forget to ask if stuck. Tinderbox is a big toolbox and one of us knows every part, but question can find someone who knows the ones we ourselves don’t. :slight_smile:

I see @satikusala is replying so I suspect some useful links to his great tutorials are inbound next.

Hi @Dthomp310, I have no idea what you’re agents are doing, however, over the last 9 months, I have found a ton of different way to optimize my agent strategy, including caching variables, using conditional checks, bringing in boolean attribute checks, turning off action code on specific notes when it is no longer needed. Most of this is listed above in @mwra’s notes, some not; in the end, your optimizing will depend on your circumstance. It is possible that there are some workflow enhancements and not organization strategies that can help. More…If you’re interested, we can hop on a call to discuss. “Optimizing agents” could make for a good Mastering Tinderbox YouTube video. :wink: Would love to discuss this with you. DM me if you’re interested.

Also, RE the image point, you can use markdown and HTML to reference your images rather than embedding them. Finally, three is an interesting use of $Fill that I’ve been exploring. Again, the use of these strategies will depend on your context.

For what it’s worth, even heavy use of agents is unlikely in itself to cause perceptible delays in current Tinderbox. Nor are rules likely to cause problems.

Two things are likely culprits here.

  1. It’s possible to write rules that need to examine not only this note, but also every other note. This works in small documents because there aren’t that many notes. In a document with 1000 notes, though, one rule pass has to examine 1000 × 1000 =1,000,000 notes. That can add up eventually.

  2. Documents with lots of images (or immense amounts of text — libraries rather than a book or two) occupy lots of disk space, which is not a big expense, and take longer to save. That, again, is usually not a big worry. But, if your document uses lots of rules and agents, it’s likely that it’s constantly updating itself – and so it autosaves frequently. I suspect this is what was bothering @Dthomp310.

Happy to take a look at the problem, but I suspect the current revisions will cure it.