From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20178 invoked from network); 10 Jun 1999 09:56:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Jun 1999 09:56:04 -0000 Received: (qmail 29773 invoked by alias); 10 Jun 1999 09:55:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6564 Received: (qmail 29765 invoked from network); 10 Jun 1999 09:55:46 -0000 Message-Id: <9906100927.AA23734@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: Re: trying to make things a bit faster... In-Reply-To: "Sven Wischnowsky"'s message of "Tue, 08 Jun 1999 15:35:58 DFT." <199906081335.PAA14629@beta.informatik.hu-berlin.de> Date: Thu, 10 Jun 1999 11:27:02 +0200 From: Peter Stephenson Sven Wischnowsky wrote: > p-mem-1 > This is a relatively small and safe patch that makes zhalloc() a bit > faster. Previously, it had to go through all heaps until it found > one with enough free memory. but often the first heaps in the list > were completely full. So this patch adds a pointer to the first heap > with free memory and keeps it up-to-date on heap operations. Then > zhalloc() can start it's search at this heap. I had this same idea. I also found out it didn't make that much difference. Actually, it wasn't quite the same: it also skipped heaps which had less than a small amount of memory (16 or 32 bytes or something) left. But it still didn't seem to make much difference. > p-mem-2 > (I'm not too sure about this one... And it only has an effect when > using the zsh allocator.) > zsh has the habit of returning memory to the system as soon as > possible and to get as few memory from the system as needed. This > sometimes results in an impressive number of sbrk()s and brk()s. > So this patch makes it sbrk() more memory than it actually needs > (thinking about future allocs) and return memory only if the size of > the free chunk at the end exceeds a certain limit. > It also increases some other limits (heap size, maximum size of > small blocks, number of small blocks allocated in advance). I only use the zsh memory routines on one machine, so I can't test this all that well. (I'm still worried something nasty may be happening here with --enable-lfs, too, but in a compiler-dependent way.) > p-exec-1 > Several things: I think we just have to put all this in and try it. > p-exec-2 > The most interesting of all these patches. It can only be applied on > top of p-exec-1 and saves even more calls to zhalloc(). > It changes the execution code to not duplicate the node-tree any > more (well, only in very few places). This also means that functions > and the like are not simplified/expanded any more when duplicated > into real/heap memory. > Unfortunately, there are some places which make me fear that we > can't do this without some more work (I've put comments like > /*---- ... */ in those places): in exec.c we call simplifyright() > which changes the node tree it gets -- we can't do that anymore if > the tree is not duplicated. I tried to trigger the case where it > really modifies the tree but couldn't get it to happen. Does anyone > remember what this was for? I put in a DPUTS at the end of simplifyright() and it doesn't seem to get triggered for me either, so far. I thought it was for really simple commands, like a single command given on the command line? But they same to arrive with l->right null anyway. There's no other case where simplification matters so much, so I suggest we just delete it. > Also, there are three places in exec.c > where the node tree is modified directly, setting some pointers to > NULL. Again, I don't remember what this was for and when I changed > those assignments to (the equivalent of) `foo = (List) -1' in the > version that duplicates node trees, I couldn't get zsh to use such a > pointer. Does anyone remember why we have these assignments? > Finally, this patch avoids ztrdup()ing the pwd for every job (I > wanted to put that into p-exec-1 and then forgot to do so). It could be really ancient pfalstad stuff where he wanted to track how things we getting executed. They're all cases where that seems to be the only possible use. Completion with correction, which was pretty slow before, seems a lot faster. I can't seem myself removing these patches unless somebody can think of a good reason. -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy