tech-pkg archive

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

Re: pkgsrc performance



On Wed, Feb 25, 2009 at 05:00:25PM +0100, Joachim König wrote:
> Quentin Garnier wrote:
>> Before we jump the gun, I think we should have a try to see how much of
>> a difference it does, performance-wise.  From just modding glib2's
>> bl3.mk file, I know that pcre's bl3.mk files is included about 3 times
>> less according to ktrace, when running make in gnome-control-center.
>> But I haven't measured the time it takes.
>>
>> Also, it gains very little to modify the bl3.mk files that don't include
>> any other, which I think is a big part of them, so we can concentrate on
>> those who include other bl3.mk files first.
>>
>> I intend to have a try at descending the include tree from
>> gnome-control-center and see how much of an impact each level makes.
> Could the buildlink3.mk including not be combined with the simplification
> of the DEPENDS variable format as dicussed in the
> "enforcing pkgsrc/category/$PKGBASE" thread?
>
> E.g. the bmake infrastructure on seeing a simple "category/pkgname"
> dependency could check if a buildlink3.mk file exists there and load
> it (if it has not yet been loaded) etc. For me, the culprit is that instead
> of declaring the dependency and later evaluating/checking all the  
> dependencies,
> the corresponding buildlink3.mk is immediately included with ".include".
> Can't we decouple that?

It's an orthogonal issue.  The problem here is bl3.mk files including
other bl3.mk files.  What you describe is essentially changing a
recursive algorithm into an iterative one;  that doesn't solve the issue
here which is to know what information can be discarded when discovering
dependencies.

That said, your approach is interesting;  it would centralize the code
where it is decided whether or not to go on with the discovery, instead
of using .if !defined() blocks.  But it would still require changing all
bl3.mk files, so the amount of work is at least equivalent.

And performance-wise, I don't think it would change much.  The recursion
involved here, once it is controlled like I suggest, shouldn't have a
big impact on resource consumption.  It'd be interesting to know the
difference between the two approaches, but it's a lot of work.

-- 
Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpsHngwnvKwh.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index