Hi,
I try to collect all IMAP Folders in Apple Mail and I want the complete folder paths. With this code I get all the references to the mailboxes:
tell application "Mail"
set folders to mailboxes
repeat with theAccount in accounts
set folders to folders & mailboxes of theAccount
end repeat
return folders
end tell
The entries don’t have a property with the path, but Script Debugger shows me this result. How to get the highlighted part of the objects with AppleScript?
Each mailbox can get parent mailbox.
So, you can go up to root.
Thanks, I already tried it, but building a list of 286 folders is quite slow with 4 seconds. Maybe this can be optimized? I thought it would be faster to access the information which seems to be already there.
tell application "Mail"
set folders to mailboxes
repeat with theAccount in accounts
set folders to folders & (mailboxes of theAccount)
end repeat
set allPaths to {}
repeat with theFolder in folders
set thePath to ""
set subFolder to theFolder
repeat
try
set thePath to name of subFolder & "/" & thePath
set subFolder to container of subFolder
on error
exit repeat
end try
end repeat
try
get name of account of theFolder
on error
set thePath to "Local/" & thePath
end try
set allPaths to allPaths & {characters 1 thru -2 of thePath as string}
end repeat
end tell
Execution speed depends on how many messages and mailboxes and the depth of each mailboxes.
My Mail.app env store hundreds of mailing lists.
My M1 Mac mini + macOS 13.6 env’s result with 286 mailboxes:
Your logic (+ little fix): 32.01 sec
My logic : 29.01 sec
Your logic (+ full speed update): 19.32
These scripts calculate full Mail box path from selected mailboxes.
This is not a strict benchmark. But after some times execution, this trend is reasonable for me.
Generally speaking, your script is not so slow.
Thanks for the improvements, Piyomaru. That’s great.
Why does storing the arrays in a script speed up the execution?
Reading huge list take a long time.
This figure is from my book “AppleScript speed up technics”
Direct list access take a long time. And indirect list access is faster than direct.
I don’t know about the mechanism. AppleScript’s array (list) can store various object.
So, its address calculation took a long time, I think.
We experienced this phenomenon in Classic MacOS era (a reference to).
Storing list in script object is new technic in Mac OS X era.
Normal list access script took 15 secs with my M1 Mac mini
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
property aList : {}
set a1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set aList to {}
repeat with i from 1 to 30000
set the end of aList to i
end repeat
repeat with i in aList
set aStr to i as string
end repeat
set b1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set c1Dat to (b1Dat - a1Dat)
--> 15.198549985886
Indirect list access (a reference to) took 0.44 secs
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
property aList : {}
set a1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set aList_ref to a reference to aList
set aList to {}
repeat with i from 1 to 30000
set the end of aList_ref to i
end repeat
repeat with i in aList_ref
set aStr to i as string
end repeat
set b1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set c1Dat to (b1Dat - a1Dat)
--> 0.439829945564
property in script object is the fastest access. It took 0.39 secs
use AppleScript version "2.4"
use scripting additions
use framework "Foundation"
script hgs
property aList : {}
end script
set a1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set (aList of hgs) to {}
repeat with i from 1 to 30000
set the end of (aList of hgs) to i
end repeat
repeat with i in (aList of hgs)
set aStr to i as string
end repeat
set b1Dat to current application's NSDate's timeIntervalSinceReferenceDate()
set c1Dat to (b1Dat - a1Dat)
--> 0.38650393486
Thanks a lot for sharing this. Very interesting.
That’s great info, thanks. The speed difference is indeed huge in your example.
Could reproduce the same results on my side, too.
I never knew about it. It also made me wonder why I never experienced any kind of noticeable delay when iterating through lists using the direct access.
I guess I just never had to deal with lists that contain thousands (let alone tens of thousands) of objects.
I ran some additional tests and it looks like that humanly noticeable difference in speed starts from about 4000 objects in your example.