Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: trying to make things a bit faster...



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 <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy



Messages sorted by: Reverse Date, Date, Thread, Author