I think all the GUIs cache most of the port data if only because they
need to display it and display different views of it rapidly. There
is no use for having the port command allocate something on the order
of 5 megs of RAM and walk the tree just to run a faster search. The
GUIs have the luxury of long training - users kind of expect it to
take a little longer to start before running fast, while CLIs need to
be fast and lean.
On 23 Sep 2007, at 14:21, Kevin Walzer wrote:
Ryan Schmidt wrote:
So.... it sounds like people want this feature, so.... it sounds
like it should be put into base, rather than having each GUI have
to reimplement it. And if "port search" was too slow, and you came
up with something faster, why don't we put that in base as well?
PortAuthority's method works by running "port list" on startup,
caching the data, then iterating through that when the user
searches for a term. It's faster than "port search" only because it
doesn't have to launch a new process of tclsh when the user
searches for a term. This method make sense for a GUI because it
reduces the number of times it has to call out to the command-line
tool, but it doesn't represent any sort of improvement in the
command-line tool itself. Imagine having port run "port list" every
time it started up...the result would be slower, not faster.
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Randall Wood
[EMAIL PROTECTED]
http://shyramblings.blogspot.com
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
