|
From: Eric S. <mas...@gm...> - 2011-05-20 14:27:36
|
Hi all I have profiled two source code examples [1], [2] using Valgrind's massif. The following command has been used # valgrind --tool=massif --time-unit=B --stacks=yes --massif-out-file=<name_of_executable>.massif.out ./<name_of_executable> The output file has been printed w/ ms_print. [3] is the print for [1] . [4] is the print for [2] . The difference between the two samples is that in [1] the vector is resized before adding elements, thus no additional memory allocations should be necessary for [1] . The print expected for [1] is a rectangle, this holds true. Since the vector size for [2] needs to be increased while running the for-loop a stair-funtion should be shown, increasing steadily. However, my graph for [2] falls in between as opposed to [1] . Even though the same container (vector<>) has been used. Is this a known behaviour for vector<>'s standard allocator to allocate and hand back like this? Does anyone know why this is the case? - Sorry for might posting C++ related question. Many thanks for your contributions Eric [1]...vectorResize.cpp [2]...vectorNOResize.cpp [3]...vectorResize.ms_print.txt [4]...vectorNOResize.ms_print.txt |
|
From: Nicholas N. <n.n...@gm...> - 2011-06-01 05:11:49
|
On Sat, May 21, 2011 at 12:27 AM, Eric Schwarz <mas...@gm...> wrote: > > Is this a known behaviour for vector<>'s standard allocator to allocate and > hand back like this? > > Does anyone know why this is the case? - Sorry for might posting C++ related > question. A C++ vector implementation might do all sorts of things you don't expect w.r.t. memory management. In short, I wouldn't be surprised by much. Nick |