Subject: Re: Make's memory (mis)management (was: Re: new vfork(2) implementation)
To: None <current-users@NetBSD.ORG>
From: Christos Zoulas <email@example.com>
Date: 01/05/1998 08:11:47
In article <199801042044.VAA16584@vader.runit.sintef.no> Havard.Eidnes@runit.sintef.no writes:
>> (vfork() makes more of a difference if the process is large in
>> terms of address space use, and since make isn't very good
>> about managing memory.... :-)
>Hm, yes, I've noticed that 'make' can grow pretty large... It seems
>that this is a known fact -- can someone who's looked more than 5
>minutes at the code tell me/us a few words about how difficult it
>would be to close some (most?) of the leaks (assuming that memory
>leaks is indeed the problem)?
Memory leaks is not the problem. The major problem is the use of really
large data structures and O(n^2) algorithms. Make is using mostly linked
lists, where in places it should be using hash tables, trees or other
more efficient ADT's.
The big list of things to do in make is:
- Add pattern support.
- Fix the ADT problems, rewriting some of the file caching logic.
- Use lex/yacc to parse the Makefiles instead of the ad hoc scanning.
- Rewrite the variable expansion code.