Re: Using shell commands versus C equivalents

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

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: ANNOUNCE: DJGPP port of GNU Make 3.81 uploaded
    ... This is a port of GNU Make 3.81 to MSDOS/DJGPP. ... After inspecting the bug mailing list of GNU make I found a patch ... looks for SHELL in the environment to use that shell in the hope ...
    (comp.os.msdos.djgpp)
  • Re: OT The Sex Industry: A Multicultural Problem
    ... There are tales of some First Lieutenants having the job of inspecting the "wives" as they came alongside in port, and only allowing the more attractive ones aboard: reputation of the ship and all that... ...
    (sci.military.naval)