Re: Fast KeyChain Functions...
Re: Fast KeyChain Functions...
- Subject: Re: Fast KeyChain Functions...
- From: kai <email@hidden>
- Date: Thu, 26 May 2005 23:22:01 +0100
On Thursday, May 26, 2005, at 05:37 pm, David Crowe wrote:
Kai;
I have tested some of the scriptlets that you provided regarding the
KeyChain.
Thanks, David.
Here are my results (using 10.3.9 Panther):
tell application "Keychain Scripting" to tell current keychain to try
name of keys whose name is (get name of key -1)
on error e number n
e & " (" & n & ")"
end try
This script works, but is very slow (almost 30 seconds on my 800 MHz
TiBook). Plus it requires me to know the index of the key. However, if
I substitute the name I'm looking for, it still works, but still takes
about 30 seconds.
I inserted the indexed key to make it easier to use the script for
testing on any machine - without the need for anyone to come up with
the name of a key, or for typing it. The script wasn't intended as
anything more useful than that.
The timing thing is quite intriguing. Firstly, I'd expect a difference
between the first time such a script is run - and any subsequent runs.
This is because of the time taken to initially launch Keychain
Scripting (which is just over a second here). The application should
then remain available for a couple of minutes after any call made to
it. Secondly, your timings are very different to mine...
Based on this script it appears that the functionality of KeyChain has
been improved (i.e. you can query a key by name, not just by index
number), but not the speed. This may be because I have 238 items in
my Keychain. With a small keychain database, the performance problem
might not be so obvious.
Certainly some timing variations can be explained by the different
number of items - but I can't help thinking that it's only part of the
story. The keychain I'm using for testing is about one third the size
of yours, so I'd expect some speed gains OMM from that. However, I'm
also testing on a slower (500 MHz G3) machine - where the above script
executes initially within just over 2 seconds - and subsequently under
1 second. That's a huge difference from your figures, suggesting that
either the filtering algorithm is extremely inefficient - or that
something else is hindering execution in 10.3.9 (and possibly
elsewhere).
Ironically, using "name of every key" (i.e. without qualification)
takes only 10 seconds. Still a long time. But it shows that it would
be quicker to scan the list of names and access by index number. But
this is still several times slower than my scripts, as complex as they
might be.
By avoiding any filtering, things are faster here, too - with execution
times down to about one third of a second. However, given the speeds
you're experiencing, I really can't blame you for striving to achieve a
more efficient method. :-)
The other script you suggested:
property k : ""
set m to "Please enter a key to find its password:"
repeat
set k to (display dialog m default answer k buttons ¬
{"Cancel", "Find..."} default button 2)'s text returned
try
tell application "Keychain Scripting" to tell current
keychain ¬
to set p to password of first key whose name is k
set m to "The password for \"" & k & "\" is \"" & p &
"\"."
on error errmsg number n
if n is -128 then error number n
set m to "Could not get password for \"" & ¬
k & "\". Please try again." & return & errmsg
end try
end repeat
... did not work. The error message that I received was <Can't get
password of key 1 of current keychain whose name = "Jane">
That's probably the same error (number -1728: errAENoSuchObject) to
which Gary referred earlier. It's interesting that you can get "keys
whose name is x", but not "first key whose name is x". That, combined
with the performance issues, leads me to suspect that this area must
have sustained some damage in Panther. And we still don't know if any
of these issues have spilled over into Tiger. (Any takers?)
Thanks again for the information. :-)
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden