Re: [Boost-users] Memory problem using shared_ptr w/ STL-containers, gcc
And thus spake "Baranowski, Daniel" <dbaranowski@LSIJAX.COM> Thu, 19 Oct 2006 14:25:46 -0400:
You'll see that the objects are or are not getting destroyed (they are on my comp). I played around with this in VC 8 and the memory usage didn't go up like yours. Here's how it looks on my system:
Well, I have to apologise in one respect, the memory definitely gets re-used, which is a relief. What remains is the impossibly-large memory footprint of >10kb per object, which I have to investigate further. At the moment it is such that a list of a little over 5000 (small) POD objects eats well over 100MB of memory, and that just can't be right... however I will check if this is really caused by the shared_ptr...
Anyway, thank you all for your suggestions and your time. You have been a great help.
Regards, Robert
Hi, As what Andrew has already mentioned, using shared_ptr for simple POD is way too heavy in terms of memory overhead. I'd suggest you try two alternatives and see which one fits you more: 1) Store the POD directly in your container. AFAIK, copying 2 integers in and out of the container is not heavy at all in most cases. So that might help remove the trouble of using shared_ptr all together. 2) If you insist on storing pointer to the POD in the container, why not take a look at Boost.Pointer_Container library? The library provides the whole range of containers for pointer types. Better still, memory management on destruction is automatic in the pointer containers. Hope this helps... Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu@volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.
And thus spake "Wu Yinghui, Freddie" <yhwu@volumeinteractions.com> Fri, 20 Oct 2006 10:48:52 +0800:
1) Store the POD directly in your container. AFAIK, copying 2 integers in and out of the container is not heavy at all in most cases. So that might help remove the trouble of using shared_ptr all together.
Well, my example was boiled-down. In fact, so very much boiled down that it did not allow me to see that my problem was in fact connected to my actual structure, which is a POD container a bit larger than 2 integers. Furthermore it is used a lot at different places, so copying a pointer is definitely cheaper-- even if it is a shared_ptr. The actual problem was PEBKAC: a supposed-to-be-static member (a stringstream), that was there for data conversion purposes and because it made more sense than making it global, was not after all static and got re-created thousands of times. So my POD container was not, after all, POD. Actually, I am a bit embarassed about this... lesson learned: never ever code at 3:00 in the morning, and if you do it anyway, look for problems in your own code rather than blaming some library...
2) If you insist on storing pointer to the POD in the container, why not take a look at Boost.Pointer_Container library? The library provides the whole range of containers for pointer types. Better still, memory management on destruction is automatic in the pointer containers.
Thanks for the suggestion, this sounds very interesting. I will definitely look into it. Regards, Robert
participants (3)
-
Robert Fendt -
Wu Yinghui, Freddie