Date: Sat, 16 Jun 2007 23:47:51 -0700 From: Garrett Cooper <youshi10@u.washington.edu> To: Tim Kientzle <kientzle@freebsd.org> Cc: hackers@freebsd.org Subject: Re: Using shell commands versus C equivalents Message-ID: <4674D917.7000502@u.washington.edu> In-Reply-To: <4674BE32.300@freebsd.org> References: <Pine.LNX.4.43.0706131018120.25469@hymn01.u.washington.edu> <46703EE9.1030804@freebsd.org> <4674B268.4030502@u.washington.edu> <4674BE32.300@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4674D917.7000502>