I should add that I would like it to be automatic, rather than having to use a stamp to set the categories via my rule every time I add a note.

--b

Thanks, Mark, but I do want the categories to be set right away, so that anytime I look at my Attr Browser window that summarizes where I'm spending my time, it will be current.

OnAdd won't work - that's what I meant when I said "parent action" in my original post. The category gets set after OnAdd processing is done - after I type the name of the note and hit Return. I tested it.

Is there (or might there be at some point) a kind of Run Edicts Now command, maybe analogous to Update Agents Now? That might be the best of both worlds. I could just run the Edicts when I need to see my summary info.

For now, I'll just go with what I've got.

Thanks -- Barbara

Hi --

OK I am trying an agent. My rule does indeed contain a series of about 40 or so if statements, and yes, they are all .contains() looking at $Name. if $Name.icontains("abc) then $category = $category+"xyz" etc. So I moved all that into the agent.

Of course, now my (streamlined) rule run on almost twice as many notes, because it runs on all the originals plus all the aliases collected by the agent. And I still need other parts of the rule that calculate other values, e.g. it sets the end time of one note based on the start time of the next note, but I guess that will not use as much processing power. And now that I think about it, I might be able to move some of that processing into the onAdd statement. Maybe I'll play with that.

Thanks for the help -- Barbara

Backing up a level: what is the underlying concern here?  Why do we want efficiency?

Some possibilities might include:

• Preferring less delay between making a change and seeing Tinderbox respond to the change.
• Preferring to reduce power consumption.
• Concerns over interference with other CPU-hungry processes.
• Traffic jams, where Tinderbox can't finish evaluating all the rules before it's time to start over again.
• Something else.

My impression is that, for most projects and most people, none of these concerns are likely to matter. So, most of the time, efficiency is good for style points and that’s about all.

Agents tend to do less computational work than rules, and edicts do less computational work than agents.  This can matter for battery life or for interference with other processes, things that might be a concern, for example, if (a) you spend a lot of time on intercontinental flights, or (b) you're a professional film editor and you're working on location.

The problem of traffic jams used to be real. I've heard of only one potential case with Tinderbox Six, though, and unless you're doing really wild things with rules, it's not going to be a problem for you.

But, also, it's always satisfying to do things well. There's no point in making your computer do more work than necessary; it doesn’t care one way or another, but it's nicer to say

    inside(/archives) & $Text.contains(....some complex expression....)

where we reject 95% of the cases instantly because they’re not in the archives, than the equivalent

    $Text.contains(....some complex expression....) & inside(/archives)

where we do lots of work to find notes with a complicated expression, but often then throw it away because, no, that note isn't inside archives so never mind.  Our slaves of sand and steel don’t actually care either way, but our sympathy suggests that it's better not to do the extra work.

Now we've unpicked the overall issue of efficiency in performance terms, I'd suggest that a rule/agent/edict needing 40 if() clauses is a prompt for some refactoring.

It sounds like you effectively have a controlled vocabulary of 40 categories (which may rise or fall a bit over time). Consider the suggestions here about pre-populating a list. With that set up then pretty easy to either:

• Manually set the category from a drop down when the note is made, or if automation is still a must,
• values("category") gives you list of all unique $category values which can then be iterated via list.each.

The latter would give some flex even if you still end up doing .contains() searches as the list will vary as the list of $category changes over time.

The context where you use that list - in terms of rule/edict/agent action - is up to the user  and has already been discussed above.