Improved boost::any
I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest? Christopher Diggins http://www.cdiggins.com
----- Original Message ----- From: "christopher diggins" <cdiggins@videotron.ca> To: "Boost mailing list" <boost@lists.boost.org> Sent: Monday, August 08, 2005 6:48 PM Subject: [boost] Improved boost::any
I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest?
Sorry to respond to my own post, but the pretentious subject line has me embarassed. It is by no means an "improved" boost::any. It is a performance enhanced version, but as a colleague pointed out it is not exception safe. So in fact it is a worse version :-( but perhaps the performance enhancements may pique some people's interest. Christopher Diggins http://www.cdiggins.com
christopher diggins writes:
I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest?
Sorry to respond to my own post, but the pretentious subject line has me embarassed. It is by no means an "improved" boost::any. It is a performance enhanced version, but as a colleague pointed out it is not exception safe. So in fact it is a worse version :-( but perhaps the performance enhancements may pique some people's interest.
FWIW, we (Meta) would be definitely interested in a version that boosts any's perfomance without compromising its exception safety guarantees ;). -- Aleksey Gurtovoy MetaCommunications Engineering
christopher diggins wrote:
I have developed a type very similar to boost::any which requires less memory and significantly reduces the number of allocations / deallocations. If anyone is interested I have posted a brief article about it at CodeProject http://www.codeproject.com/useritems/dynamic_typing.asp and I have uploaded the source to the vault ( http://boost-sandbox.sourceforge.net/vault/index.php ). Is there any interest?
If the trick is to use "void*" pointer to data for storing data when it's small, then: - it's interesting to see performance comparison for any<string>, or any<some_other_large_class> - can't this be just patch to boost::any, as opposed to completely different class? - Volodya
----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su>
If the trick is to use "void*" pointer to data for storing data when it's small, then:
- it's interesting to see performance comparison for any<string>, or any<some_other_large_class>
Another part of the optimization, is to avoid reallocating when reassigning any a different value with the same type. On a related note: several people have suggested that a buffer should be used with an arbitrary size set at compile time, which would help significantly for container types.
- can't this be just patch to boost::any, as opposed to completely different class?
What does submitting a patch entail? Is that the way to go if the implementation is completely different? - Chriostopher Diggins
christopher diggins wrote:
----- Original Message ----- From: "Vladimir Prus" <ghost@cs.msu.su>
If the trick is to use "void*" pointer to data for storing data when it's small, then:
- it's interesting to see performance comparison for any<string>, or any<some_other_large_class>
Another part of the optimization, is to avoid reallocating when reassigning any a different value with the same type.
Ok.
On a related note: several people have suggested that a buffer should be used with an arbitrary size set at compile time, which would help significantly for container types.
- can't this be just patch to boost::any, as opposed to completely different class?
What does submitting a patch entail?
Well, you submit a patch and it's either applied or not ;-)
Is that the way to go if the implementation is completely different?
That's the question! Can your optimization ideas be formed as small changes to existing boost::any, as opposed to completely different implementation? - Volodya
Hi, Christopher asked me if I would be willing to pursue the submission of this to boost... so I'll give it a shot. Here's what I've managed to do so far: As far as portability is concerned, * Its working and passed basic tests on: - VC6 SP6 - VC7.1 - BCB6 * Compiles ok, but can't be run with: - Como's online compiler (4.33 beta in strict mode) The the runtime tests show significant improvement, as Christopher said, for his original tests, and adding an std::string test shows this version to be roughly twice as fast as boost::any Some thing I would like help on is, is it necessary to ensure alignment for types who's size is <= sizeof(void*) ? The updated version, along with project files for the 3 compilers above mentioned, is available at: http://tinyurl.com/dj5pk or www.geocities.com/pablo_aguilarg/cdiggins_any_update.zip I tried registering at the sandbox, but got an error, I guess I should try later. Comments? Pablo
Pablo Aguilar wrote:
I tried registering at the sandbox, but got an error, I guess I should try later.
What error did you get? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
From: Rene Rivera <grafik.list@redshift-software.com>
Pablo Aguilar wrote:
I tried registering at the sandbox, but got an error, I guess I should try later.
What error did you get?
We should mention that the sandbox uses a completely separate login from SourceForge, Boost MLs, etc. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rene Rivera wrote:
Pablo Aguilar wrote:
I tried registering at the sandbox, but got an error, I guess I should try later.
What error did you get?
A timeout error of some sort... I figured I should just wait it out instead of asking for help. I just tried again, and have now successfully registered. Thanks for offering to help. Pablo
Hi Pablo Pablo Aguilar wrote:
Some thing I would like help on is, is it necessary to ensure alignment for types who's size is <= sizeof(void*) ?
Yes, AFAICT. Have a look at Boost.Optional, which uses alignment_of for all types...
The updated version, along with project files for the 3 compilers above mentioned, is available at:
http://tinyurl.com/dj5pk or www.geocities.com/pablo_aguilarg/cdiggins_any_update.zip
Your version is interface-compatible with the version currently in boost, right? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Yes, AFAICT. Have a look at Boost.Optional, which uses alignment_of for all types...
Thanks! Will do...
The updated version, along with project files for the 3 compilers above mentioned, is available at:
http://tinyurl.com/dj5pk or www.geocities.com/pablo_aguilarg/cdiggins_any_update.zip
Your version is interface-compatible with the version currently in boost, right?
Regards,
Just about, it's still got get_type instead of type (but you can easily patch that for testing). We're still working on alignment problems, and should have an update available later today. Pablo
Pablo Aguilar <pablo.aguilar <at> gmail.com> writes:
Your version is interface-compatible with the version currently in boost, right?
Regards,
Just about, it's still got get_type instead of type (but you can easily patch that for testing).
Like Vladimir, I would prefer if the interface is just like the one of Boost.Any. For an arbitrary size buffer you'd probably need an additional (defaulted) template parameter but that's about it for interface changes. So, this is more of a "patch" for the Boost.Any *implementation*. Don't know whether the original author is willing to review such a patch. If not we might want to schedule a mini-review... Thoughts? Regards, Andreas -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
"Andreas Huber" <ahd6974-spamgroupstrap@yahoo.com> wrote in message news:loom.20050810T132441-386@post.gmane.org...
Like Vladimir, I would prefer if the interface is just like the one of Boost.Any. For an arbitrary size buffer you'd probably need an additional (defaulted) template parameter but that's about it for interface changes.
Oh, we completely agree.. it's just that I didn't get around to changing things, and didn't actually notice until after I posted. There's a newer (though still in work) version available here: http://tinyurl.com/9wv28 Christopher is currently looking into a way to fix alignment issues (I looked at Optional, and it turns out it has the advantage of knowing beforehand the type it is to store, whereas any can't know that in advance), so we'll probably have a better version some time later today.
So, this is more of a "patch" for the Boost.Any *implementation*. Don't know whether the original author is willing to review such a patch. If not we might want to schedule a mini-review...
Thoughts?
Could be, we'll see how changes currently in work can be fit into any's current implementation.
Regards,
Andreas
-- Andreas Huber
Thanks for your feedback. Pablo
participants (7)
-
Aleksey Gurtovoy -
Andreas Huber -
christopher diggins -
Pablo Aguilar -
Rene Rivera -
Rob Stewart -
Vladimir Prus