0

I upgraded a server to FreeBSD-10/gcc48, and my project, which uses ar to put subprojects into static libraries, now links outrageously slowly.

10.0-RELEASE-p4 FreeBSD 10.0-RELEASE-p4 #0: Tue Jun  3 13:14:57 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Playing with different ar flags:

“time ar -v -c -u -q ...” : 362.62 real 0.11 user 0.82 sys

“time ar v -c -r -u -s ...”: 407.94 real 0.13 user 0.80 sys

This must be ten times slower than before (FreeBSD-8, stock GCC compiler). What can I do to improve this? GNU Libtool just uses ar behind the scenes (so wouldn't help), right? Should I bypass static libs altogether? (But wouldn't building a .so take the same time?) Needless to say, this kills my development cycle time.

JimB
  • 971
  • 8
  • 20
  • 1
    Since the user and sys time is small, you seem to spending time in IO. So do some tuning around that e.g. make sure you have enough RAM and are not swapping. Try another filesystem, or try placing your object files and library on a memory disk. Also test performance when creating a brand new static library, vs when the library already exist(since you provide the -u flag). Also check without the -u flag. – nos Oct 13 '14 at 13:33

2 Answers2

2

This issue is caused by ar(1)'s I/O access pattern interacting with kernel UFS deadlock avoidance code, and is fixed in FreeBSD r284298. This will be available in FreeBSD-CURRENT snapshot builds in mid July 2015, and should be backported for FreeBSD 10.2.

emaste
  • 21
  • 3
0

Unable to resolve ar and not seeing it with anything else, I constructed a RAM-disk just big enough to hold my biggest ar output file, then hacked my build to output ar there, then mv the file to the original destination.

This fixes the performance issue and is a pretty self-contained work-around, but you can imagine the caveats. (Creating the RAM-disk requires root access, holds a resource you only need temporarily, doesn't scale well for multiple tasks, etc.).

JimB
  • 971
  • 8
  • 20