tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkgsrc performance

Roland Illig wrote:
Jared D. McNeill schrieb:
On a 266MHz Geode GX:

  $ time make show-var VARNAME=PKGNAME
   1268.48s real   815.57s user   356.51s system

This is a joke, right?

Unfortunately, it is a very bad and true joke. One of the reasons is
that the files are loaded and parsed over and over:

$ strace | grep open | sort | uniq -c | sort -nr
  21021 open("../../mk/",
   5572 open("../../x11/xproto/",
   4505 open("../../converters/libiconv/",
   2445 open("../../x11/kbproto/",
   2443 open("../../x11/libXdmcp/",
   2443 open("../../x11/libXau/",
   2443 open("../../x11/libX11/",
   2302 open("../../mk/buildlink3/",
   2302 open("../../mk/buildlink3/",
   2302 open("../../mk/buildlink3/",
   2216 open("../../devel/gettext-lib/",
   2210 open("../../devel/gettext-lib/",
   1905 open("../../devel/zlib/",
   1631 open("../../graphics/freetype2/",
   1335 open("../../mk/",
   1248 open("../../textproc/expat/",
   1167 open("../../devel/pcre/",
   1167 open("../../devel/glib2/",

We could surely avoid that by changing _all_ these files to the order
known from C header files:


.include "../../dependency/one/"
.include "../../dependency/two/"



That would be all. But this change involves lots of subtleties that only
jlam@ understands. I asked some years ago whether to make that change,
but didn't dare to start the whole work.

It seems certain packages are orders worse than others. Is it related to number of dependencies, or dependency ordering do you think?

Home | Main Index | Thread Index | Old Index