I’ve noticed that with small (as in not many notes, rules, edicts, etc.) files, stamps process pretty much straight away, but with larger, more complex files there can be a bit of a lag. I’m assuming that being based on action code, they dutifully wait their turn until firing. Is this correct?
Thanks in advance!
Essentially. In outline, the stamped selections selection outline redraws an empty box when the stamp has finished acting on every selection in term.
Yes, stamp actions go into the pending tasks queue.
My experience has been that it’s actually quite rare for this queue to be so full that there is typically any appreciable delay — even in larger documents. It’s certainly possible — Mark Anderson was chronically in this regime in his data analysis document during his doctoral research — but I know of only one or two other cases.
Additionally, stamps might not refresh the user interface as soon as they run, especially if they don’t see a need. That’s fairly common; to check, select another note or press the currently selected tab.
I’m finding that in some of my files it can take as long as 5~10 minutes to process a stamp. But, to be clear, this a bigish files with a lot of links and prototypes.
Five minutes? That’s nuts! (I doubt the number of links or prototypes is a factor). If you can share that somehow, I’d love to know what’s going on.
To clarify, my work was in a doc with 000s of notes and each was doing a complex query across the document. I deliberately used a stamp as I knew the process would take longer than usual to run, so this gave me a chance to control the running of code in small sections.
So I was never waiting minutes, albeit because I chose to only run selections of about 50 at a time which also allowed me to check and confirm things as I went. Had I simply put the code in an Edict or rule, i suspect I’d had had to have waited a full cycle to complete. The moral being, if you know you have a complex task to run it is worth considering using more manual control. Also in this scenario I was only ever running one large file in the app at the time, again to avoid different docs fighting for the same finite resource. I wouldn’t wish to confuse those making less heavy use of the app into thinking stamp code is any slower than the same code in rules. It is simply in rare cases the user’s choice of the complexity and breadth of use of the code pushes the app hard.
I can contribute little in the context of running several complex documents at once but common sense says that one doc or 4 together all have the same finite amount of resource to run.
If you are encountering delays, look to re-factor your code. Do you need code in rules that could be in edicts. Do you need so many agents and all running at normal speed? And so on. It’s nice to feel the app should respond to any amount of work, but there have been very few cases in my files, or helping with others’ files that some revision of code won’t resolve.
I am a pretty heavy user of smart adornments, using the following query (put there by a stamp) $Created==$Created(adornment) to gather notes that have been created on a day to an adornment also created that day. Given that it’s a daily journal, every day the amount of adornments increases by 1. Do smart adornments create processing overhead?
I understand them in terms of a map-only form of container-scoped agent: the smart adornment can’t match items outside the current map. However, it is another agent in the agent cycle (albeit testing a smaller maximum number of notes).
Any query/action being evaluated has to use some resource. But, I think you are phrasing the question incorrectly. Try:
“Should I worry about using smart adornments?”
No. If you find your document is sluggish compared to others, large amounts of ‘agent’ queries may be the problem. But I’d not worry about a problem you don’t have. But, do review your work pattern. Are you using a lot of queries/code for the convenience of not remembering anything? Do remove or turn off, or throttle back un-needed or unimportant queries.
If every new document task adds lots of queries, look at more efficient query structure, e.g. (with no more detail I can’t put that more precisely). Are 10 different things all polling the same large set of data? If so, consider using 1 to do the big initial search an others within it. Think about how scale (more data, tasks, etc.) acts on your document.
There is no simple one-size-fits-all answer. But, don’t worry unduly about slowdown if you’re not encountering it. Nothing is more corrosive to progress than no acting in case some unspecified bad result occurs. Deal with the issue when it occurs.
Every note I make has an edict that will change stuff (badges mainly) based on the status of checkboxes. I’m noticing slowdowns. and I suspect that it’s the ever-growing amount of edicts sitting there. I’ll do some experiments with a duped copy and see if I can speed it up by nuking the edicts and thinking about some other way to handle it. Only maybe 5% of the notes ever actually fire their edict, so it might be a case of manually handling it.
I’m noticing slowdowns. and I suspect that it’s the ever-growing amount of edicts sitting there.
I think that’s not very likely, but much depends on exactly what is slow, and how slow it is! Happy to hook your document up to the instrumentation and to take a look if you like.
Sure thing, I’ll send a copy through to the email address. My main issue is the speed of the processing of the stamp that I use to set up and finish the adornments (titled DailyAdornSetup and DailyAdorn Finish). Sometimes there is a pretty significant lag for them to fire, going on over 10 minutes or so. [I’ll include this post copy in the email I send].
Again, 10 minutes is nuts. 10 seconds is nuts. Something is not right.