[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: KDevVarLengthArray still required?
From:       Milian Wolff <mail () milianw ! de>
Date:       2010-01-15 21:21:24
Message-ID: 201001152221.24758.mail () milianw ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 15 January 2010 21:55:09 David Nolden wrote:
> Am Dienstag 12 Januar 2010 23:38:27 schrieb Milian Wolff:
> > I thought mem-pools could use many blocks of a given size, i.e. exactly
> > the difference? I mean malloc/realloc takes one sequential chunk of
> > memory of requested size, no? And with a pool, when one needs more
> > space, one can
> > 
> >  simple add a block and store the stuff there instead of realloc'ing all
> >  the existing stuff. Or am I mixing things up?
> 
> Well yes, that can be done. But I don't believe all that stuff makes a very
> big difference in comparison to the one-block case.

I read this once: 
http://www.boost.org/doc/libs/1_41_0/libs/pool/doc/concepts.html

And I got my impression from there. And (imo) alone the fact that realloc 
requires a chunk of memory to be consecutive (i.e. must not be fragmented) is 
a big downside. Even if there is lots of free memory one could come into the 
situation where there is not a block of that size, no? Or does the 
memcontroller / kernel cover these cases? Also imagine where filesystems would 
be nowadays if they would not support fragmented files ;-)

And as my callgrinds show: 1.1k reallocs cause 3.5 mio 
IndexedQualifiedIdentifier ctor & dtor calls, which is > 70% of the total calls 
to the copy-ctor and 41% of the calls to the dtor _overall_... And both ctor & 
dtor have a pretty high "incl" cost... (11.72% & 19.31%)

See also:
http://users.physik.fu-berlin.de/~milianw/callgrind.out.29477.bz2
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread]