On Mon, Feb 14, 2005 at 02:08:07PM -0800, John-Mark Gurney wrote:
> David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
> > Right, databases, language runtimes, and the small set of other
> > applications for which it really matters usually have their own
> > special-purpose alloc
On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz <[EMAIL PROTECTED]> wrote:
> Right, databases, language runtimes, and the small set of other
> applications for which it really matters usually have their own
> special-purpose allocators. I was counting on that when I said
> that replacing malloc
On Mon, Feb 14, 2005, John-Mark Gurney wrote:
> David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
> > Right, databases, language runtimes, and the small set of other
> > applications for which it really matters usually have their own
> > special-purpose allocators. I was counti
David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
> Right, databases, language runtimes, and the small set of other
> applications for which it really matters usually have their own
> special-purpose allocators. I was counting on that when I said
> that replacing malloc() is un
On Mon, 14 Feb 2005, Uwe Doering wrote:
Just from memory, doesn't Linux' malloc require kernel support for re-mapping
memory regions, which is not available in FreeBSD? This issue came up in the
discussion about FreeBSD's anemic realloc performance. Or has this kernel
functionality been added
On Mon, Feb 14, 2005, Andrew MacIntyre wrote:
> David Schultz wrote:
> >Other than that, I don't know enough
> >details about ptmalloc to speculate, except to say that for most
> >real-world workloads on modern systems, the impact of the malloc
> >implementation is likely to be negligible. Of cour
David Schultz wrote:
Other than that, I don't know enough
details about ptmalloc to speculate, except to say that for most
real-world workloads on modern systems, the impact of the malloc
implementation is likely to be negligible. Of course, test
results would be interesting...
Some language inter
Jason Henson wrote:
On 02/13/05 03:21:29, David Schultz wrote:
[...]
With a little bit of work, you should be able to replace
src/lib/libc/stdlib/malloc.c. ptmalloc is much more heavyweight,
but it would probably do better in cases where you have a large
number of threads doing a massive number of
On 02/13/05 03:21:29, David Schultz wrote:
On Sun, Feb 13, 2005, Jason Henson wrote:
> I saw on a few of the lists here how linux uses ptmalloc2 and it
> outperforms bsd's malloc. I tried to do some research into it and
> found PHK's pdf on it and it seems bsd's malloc was ment to be ok
in
> mo
On Sun, Feb 13, 2005, Jason Henson wrote:
> I saw on a few of the lists here how linux uses ptmalloc2 and it
> outperforms bsd's malloc. I tried to do some research into it and
> found PHK's pdf on it and it seems bsd's malloc was ment to be ok in
> most every situation. Because of this it s
I saw on a few of the lists here how linux uses ptmalloc2 and it
outperforms bsd's malloc. I tried to do some research into it and
found PHK's pdf on it and it seems bsd's malloc was ment to be ok in
most every situation. Because of this it shines when primary storage is
seriously over com
11 matches
Mail list logo
