Looking for speed increases in "make index" and pkg_version for ports

Garrett Cooper youshi10 at u.washington.edu
Tue May 29 04:11:51 UTC 2007


Stephen Montgomery-Smith wrote:
> Roman Divacky wrote:
>> On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote:
>>> Jeremy Chadwick wrote:
>>>> On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith 
>>>> wrote:
>>>>> I have been thinking a lot about looking for speed increases for 
>>>>> "make index" and pkg_version and things like that.  So for example, 
>>>>> in pkg_version, it calls "make -V PKGNAME" for every installed 
>>>>> package. Now "make -V PKGNAME" should be a speedy operation, but 
>>>>> the make has to load in and analyze bsd.port.mk, a quite 
>>>>> complicated file with about 200,000 characters in it, when all it 
>>>>> is needing to do is to figure out the value of the variable PKGNAME.
>>>> I have a related question, pertaining to "make all-depends-list" and 
>>>> the
>>>> utter atrocity that is the make variable ALL-DEPENDS-LIST.  If you 
>>>> don't
>>>> know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in
>>>> bsd.ports.mk.
>>> I posted this to ports at freebsd.org, but now I am realizing that it is 
>>> hackers at freebsd.org that gets more responses.  Anyway, here is a 
>>> multithreaded program "all-depends-list" that can get you double the 
>>> speed on dual processor systems, and even some small speed gains on 
>>> single processor systems.  E.g.
>>>
>>> all-depends-list /usr/ports/x11/xorg
>>>
>>> http://www.math.missouri.edu/~stephen/all-depends-list.c
>>
>> btw.. stehpen, when are you getting a commit bit? :) I certainly hope 
>> that soon enough ;)
> 
> Probably not.  The program seems to have a bug in it.  In particular, I 
> didn't read the fgetln man page sufficiently well.  So think of it as a 
> proof of concept rather than a finished product.
> 
> I'm going to rest from this stuff for a while, but I enjoyed the 
> exchanges and it has given me encouragement to work on it again in the 
> future sometime.
> 
> Stephen

	fgetln(2) just scans ahead to the next newline, so the pointer to the 
next line is returned and the length of the string (with newline char 
included) is stored in the len variable (2nd parameter to function).

-Garrett


More information about the freebsd-ports mailing list