A question regarding the nuance in the speed of using different methods to get the property of a record

DEVONthink Automation
1

I have a question:

Just want to know which one of the below is the speediest method of extracting the properties of a record in DT? The small difference in time of execution matters when manipulating a large list and/or running a repeat loop. P.S. I have run some comparison tests under Script Debugger but the actual performance in DT may be different - that’s why I ask.

Thank you very much!

tell application id "DNtp"

-- theChild being a record in DT	
-- method 1
	tell theChild
		set {theName, theURL, theUUID, theCmt} to {theChild's name, theChild's reference URL, theChild's uuid, theChild's comment}
	end tell
-- method 2	
	set {theRecord, theName, theURL, theUUID, theCmt} to {get theChild's name, get theChild's reference URL, get theChild's uuid, get theChild's comment}
-- method 1	
	tell theChild
		set {theName, theURL, theUUID, theCmt} to {its name, its reference URL, its uuid, its comment}
	end tell
	
end tell
2

For DEVONthink it doesn’t matter actually as it always receives the same AppleEvents for each property.

3

Good to know. Thank you!

4

The bottleneck is the number of AppleEvents the script has to send: one for each property.
But there’s also a property ‘properties’. So:

tell theChild
	set props to its properties--> just one AE gets sent
	uuid of props --> no AE gets sent
end tell

Downside: you can manipulate props only in a tell DT block.

1 Like
5

Another disadvantage is that this could be even slower depending on the number of required properties (and it doesn’t seem to work, at least my test right now failed due to an internal exception of Cocoa’s AppleScript support)

6

Thanks to @alastor933 and @cgrunenberg. Get the properties as a first step is an interesting way that worth considering in some cases!

If speed optimisation is essential, it seems that the best tricks for me are:
(1) Use search in DT dictionary or use get children/parents to get a bunch of records (one AE?) and work on that list in the script.
(2) Use script object or a reference to for any list related operations (dramatic - in general).

Cheers.

7

The next release will fix this, it affects only records without text.

8

Well, it works here in 10.11.6 & DT 3.0.4.

I’ve always understood that reducing the # of AEs sent will speed up any script. The amount of data to be read per Event is of lesser concern.

1 Like
9

The properties include a lot of stuff that has to be read from disk, converted or calculated on the fly (e.g. plain/rich text, document dates/amount, digital object identifier, thumbnails etc.), therefore this is definitely not always the best option.

1 Like
10

But the next release will improve this by skipping especially those properties that require disk access, conversions or expensive calculations. Such properties can and should be individually accessed. Then ngan’s example can be implemented about 2.5 times faster (the more properties you need the greater the difference is):

		set theProperties to properties of theRecord
		set theName to name of theProperties
		set theURL to reference URL of theProperties
		set theUUID to uuid of theProperties
		set theComment to comment of theProperties
1 Like
11

This is wonderful! Can’t speak for the others but I think it will be very useful for anyone who needs to manipulate long list of records relating to properties that doesn’t need disk access. Thanks again.

12

The properties include a lot of stuff that has to be read from disk, converted or calculated on the fly…

Ah. Yes, that may be a bigger bottleneck.
I suppose that means you should run speed tests, whenever speed is a concern.

1 Like
13

Yes, I am now used to comparing different ways by timing multiple loops of the same script. It seems that the DT (the app) may get busy doing some background processes randomly so multiple loops testing is essential. This optimisation exercise is educational through which I learn how to script more efficiently for speed.

Thanks again.

14

For me, the critical path is the sorting of records by one/more of a record’s properties. Currently, I use the method of establishing a list-of-list of records and the required properties (for sortkey) as the first step, then I use script object within handler to speed up the work on sorting/manipulation of the lol. List as Script object works well for repeat loop but has no impact for recursive handler that keeps calling itself (the object keeps resetting itself - I think that’s the reason).

If properties of a record can be called in one AE, that will speed up my first stage process substantially.

Thanks for pointing out considering AE as The bottleneck, it’s an eye opener!

Not to complicate the discussion, but I wonder if using foundation (objC with all those NSS prefix?) In AppleScript will manage list of records (in DT or other apps) better/faster? Just a thought.

15

How to sort a list of records by a specific property.

I’d suggest searching MacScripter for more on ASObjC - you can use Google, or become a member so you can use their own search page.

16

I did. I think MacScripter is one of the most educational sites (at least for me) as far as AppleScript tips are a concern. Nigel Garvey and Yvan Koenig are those whose posts are giving me the most valuable insight. I also find myself re-reading the O’Reilly’s dog book more and more.

Regarding ASObjC - I am just touching the idea very lightly for now. I’d want to get a good grip on the fundamentals of AppleScript and programming first… :grinning: :thinking: :thinking:

P.S. I am from the age of Basic and Pascal, so interpretive languages like VBA or AppleScript always look more friendly to me.

1 Like
17

Yes, I was going to suggest the same. As an example, this scripting library contains four sort methods/handlers implemented in AppleScriptObjC (ASObjC). Maybe you could even use them as is.

The methods in that library are based heavily on code written by Shane Stanley whose eBook “Everyday AppleScriptObjC” is a truly great resource and I can wholeheartedly recommend it.

As another example, this script shows how to integrate some AppleScriptObjC handlers within a regular AppleScript script (w/o a scripting library).

AppleScriptObjC is the best thing that ever happened to AppleScript and it’s really useful, definitely worth checking out IMO.

1 Like
18

I often run larger scripts from Script Debugger as I write, test and then forget to add them to DEVONthink’s script menu … I assume scripts run faster if Script Debugger is not involved, but are there other advantages of running long scripts from within DEVONthink? Does DEVONthink “take breaks” in execution if it needs to?

19

No. Of course the scripts are easier to use via the Scripts menu and support even shortcuts.

1 Like