Sender: nate AT cartsys DOT com Message-ID: <36E581E0.972D4E5C@cartsys.com> Date: Tue, 09 Mar 1999 12:17:36 -0800 From: Nate Eldredge X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.1 i586) MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: Bash 2.03 updated References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: > > On Mon, 8 Mar 1999, Mark E. wrote: > > > 1) Use of GNU malloc provided by Bash. > > That figures. It's not that gmalloc is slower (I don't know if it is, > but I doubt it's significantly slower). The problem probably is just > what it looked to me: gmalloc is a relocating allocator, meaning that > it sometimes decides to relocate large buffers behind the scenes, if > it is going to run out of memory. In other words, before it calls > sbrk, it tries very hard to reuse memory it already owns. And this > relocation takes time, since it's a kind of garbage collection. ??? How can that ever work? Once `malloc' returns a pointer, it can't change it-- you're expected to be able to alias the pointer all over the place, and malloc can never find and fix them all. I know GNU has a relocating allocator scheme, but it uses indirect pointers-- you pass a `char **' and it updates the pointer as needed. It's different and incompatible. -- Nate Eldredge nate AT cartsys DOT com