I thought about the chunk idea, but if I make MPoint be 28 bytes instead of
16, memory usage nearly doubles for the same section of code, so I don't
think that's it. I suppose I'll track it down in the source eventually, but
it looks like vectors aren't a great solution in the short term.
"Keith Rollin" <[EMAIL PROTECTED]> wrote in message
news:50488@palm-dev-forum...
>
> Could it be that the C++ Std Library allocates memory from the Palm
> OS heap in chunks? That is, even if you call malloc(1), it could be
> that the library allocates 4K for it's own use, and then allocates
> from that until it's full.
>
> You've got the source code to the STL and C library, so you should be
> able to track this one down. Or you could run your experiment twice
> and see what happens.
>
> -- Keith
>
>
> At 3:25 PM -0400 5/24/01, Chris DiPierro wrote:
> >Consider the following code:
> >
> > MPoint p; // MPoint is a class ... sizeof(MPoint) == 16
> > UInt32 free, large;
> > vector<MPoint> v;
> >
> > p.x = 10;
> > p.y = 20;
> > free = sizeof(MPoint);
> > MemHeapFreeBytes (0, &free, &large);
> > v.resize (100);
> > MemHeapFreeBytes (0, &free, &large);
> > for (UInt16 c=0; c<100; c++) {
> > v[c] = p ;
> > p.x ++;
> > p.y ++;
> > }
> > MemHeapFreeBytes (0, &free, &large);
> >
> >sizeof(MPoint) == 16
> >The first MemHeapFreeBytes reveals about 230k of free heap (Palm IIIc
> >emulated).
> >The second reports 225k ... which is about 5k for 100 elements of 16
bytes
> >The final reports the same 225k value
> >
> >It works the same if I do push_back methods w/o the resize, so that's not
> >helpful. Is the Palm STL implementation *that* bad that it takes nearly 4
> >times the space necessary to store these elements?
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
