On Sep 23, 2007, at 14:50, Randall Wood wrote:
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.
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.
Understood! I agree -- that's a nice optimization for a GUI that
won't work for a CLI. Oh well. :)
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
