[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: (glibc's opinion on malloc) Re: Bug#430140: ITP: hoard -- Fast, scalable, and efficient replacement memory allocator

On Mon, Jun 25, 2007 at 08:07:55AM -0700, Russ Allbery wrote:

> The problem with this theory (basically, that glibc is taking a
> performance penalty by giving memory back to the system and hence being
> more space efficient) is that not only is Hoard significantly faster than
> glibc for OpenLDAP, it's also more space-efficient and allocates less
> total memory as soon as there are multiple clients querying the server at
> the same time.

Looking at the links there is no mention what "memory size" means here.
Is it the amount of RAM mapped, or the amount of memory dirtied?
Mapping more memory is less important (unless you're running out of
address space of course). Dirtying more memory is certainly much more


     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences

Reply to: