Assuming an Agent query matches many notes within a TB file, is there a way of limiting the number of matches.
As part of my file clean-up, I would like to identify large notes with the highest memory footprint. My initial approach was to create an Agent which retrieves all notes and sort by the newly created $EstimatedNoteSize. When I implemented the query I got a spinning ball and frozen TB app likely due to the number of notes. In practice I’m probably interested in identifying the top 20 notes or so.
Perhaps what your agent should to is search for $EstimatedNoteSize is greater than some value.
Or, instead of an agent, try using Attribute Browser for this. In an AB tab, you can display and sort by an attribute (e.g., $EstimatedNoteSize, and you can add a query to the AB to limit the results to $EstimatedNoteSize is greater than some value.
1 Like
You’re unwittingly asking the app to constantly query a calculated value.
I very much agree @PaulWalters’ suggestions. They are exactly the approaches I’ve used successfully when testing this particular attribute.
If trying to figure out a cut-off number (i.e. the X in ‘bigger than X’) find a note with a lot of content and look at the $EstimatedNoteSize and use that value as a starting point.
This is actually a bug: $EstimatedNoteSize should be reasonably fast, but as a side-effect Tinderbox was trying to typeset the note texts, which is slow. This will be fixed in the next release.
I just tried the fix on the Issues container of Note.tbx, with a couple of thousand notes that range from tiny to fairly large, and it did perform acceptably.
Another approach to sorting the container would be to use an edict to store the value of estimated note size in a user attribute
Edict:
$Estimate=$EstimatedNoteSize
and then sort on $Estimate. This would have a little less computational load, at the cost of being occasionally out of date.
Thanks for the feedback from everyone (wonderful forum by the way). I like the use of the Attribute Browser for exploring notes and their sizes.
I’ll use the workaround for the moment by specifying a threshold size in the query and wait for the next release which will allow queries on $EstimatedNoteSize on reasonable file sizes and number of notes.
For my own education - is $EstimatedNoteSize the only computed attribute and if not is there a way of knowing ahead of time what is computed and what is static ?
aTbRef has a fair amount of such classification of such things. For instance, a list of attributes that are pre-calculated.
All the read-only attributes are “computed” — they’re derived from some aspect of the document rather than stored as attributes.
To a first approximation, whether an attribute is computed or not shouldn’t matter. The problem you encountered was really a bug, and the latest backstage release does fix it.
Still, some computed attributes do take a little work to perform. For example, $DisplayName needs to evaluate the note’s display expression. Usually, that’s not much work, but it can be quite a lot if the display expression does something complicated.
Even then, this seldom matters in practice. But sorting does require lots of comparisons; if you’re sorting a list of n things, you’re going to need to make about n log n comparisons.