Tim Kientzle wrote:
Also, were the bottlenecks seen in pkg_delete and pkg_add, or does
it appear to be distributed across the board?
The biggest time sink in pkg_add is writing each file to a temp
dir then copying it to its final location. There are a couple
of strategies for avoiding this (by writing the files directly
to their final location), but it basically requires rewriting
pkg_add from scratch. I prototyped this a long time ago and
found about a 3x speedup. (Parts of that prototype eventually
became libarchive.)
I haven't looked closely at pkg_delete, but I doubt there's
much that can be done to speed it up; once you've examined the
dependency information to determine what can be deleted,
actually removing the files is a pretty straightforward
operation.
The two operations that people focus on performance issues have
been index rebuilding (which requires inspecting every port in
/usr/ports) and update (which requires inspecting every
installed port). The modular Xorg is especially going to stress
updates, since it greatly increases the number of ports on the
average system.
One useful tool: "truss" can include timing information that
can give a lot of insight into where a program is really
spending time.
Tim Kientzle
Hmmm.. not sure if you're referring to the temp creation of files in
the playpen portion of the set of programs, or something else, but as I
see it the playpen idea is a good one because it's like the Gentoo Linux
version of a sandbox, and in case something goes wrong during an install
or the user backs out, that's the way to go when dealing with a
partially created / installed package.
Maybe the strategy behind the playpen should be revised though..
Another question for everyone who's experiencing really slow pkg_add
times though -- is it maybe because of slice boundaries that need to be
crossed going from the work dir to the installation slice in moving
files, perhaps?
I'll definitely look into strace'ing (not really a big fan of
truss(1) yet) the operation though, just to see how fast or slow stuff is.
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
