On Thu 27 Aug 2009 at 09:19PM, Mike Gerdts wrote:
> Time in read_dict_file improved by over 20% (17.9 sec -> 14.2 sec) by
> inlining one tiny function.  Overall execution time improved by 13%
> (33.9 sec -> 29.6 sec).
> 
> It seems as though there are two things to consider out of this:
> 
> 1) It is not just recursive calls that are horribly expensive.
> 2) A file format that did not require parsing on every invocation
> (e.g. some sort of binary format that can just be mmap'd) would be
> very helpful.
> 
> I do not believe this is unique to sparc, as I explain in
> http://mail.opensolaris.org/pipermail/pkg-discuss/2009-August/032980.html
> (seach for Athlon), clock speed alone accounts for the bulk of the
> speed differences between sparc and x86 in "pkg list".

I think the other question to ask is whether there's a way to avoid
a full scan of the file in the first place, perhaps with an additional
table, or something else.  This goes to Bart's "ALGORITHMS ALGORITHMS
ALGORITHMS" chant/rant.

That is to say, the best way to create long lasting performance is
with good algorithms.  20% is a great win, but 2000% is more interesting.

I would also note that if you aren't running with 

10050 reading manifests during search should pick an appropriate buffer
size

It might help a little-- but its effect will depend a lot on how many
search results you are returning.

        -dp

-- 
Daniel Price, Solaris Kernel Engineering    http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to