[boost.any] Inline allocation of small objects in any.
Hi, The frequent heap usage of boost::any was problematic to me for small object sizes. So I made a small tweak in boost::any which provides inline allocation of objects smaller than a certain template defined size. It practically eliminated the performance overhead of heap allocation and deallocation in my project while providing all benefits of boost::any. You can see the changed file at http://gitorious.org/athi/athi/blobs/master/core/any.hpp It is not cleaned up, but I thought it worthwhile to have any comments from somebody who solved the same problem. Thanks, Adarsh
On 8 February 2011 20:15, Adarsh Soodan <adarshsoodan@gmail.com> wrote:
The frequent heap usage of boost::any was problematic to me for small object sizes. So I made a small tweak in boost::any which provides inline allocation of objects smaller than a certain template defined size. It practically eliminated the performance overhead of heap allocation and deallocation in my project while providing all benefits of boost::any.
What are your exception safety guarantees compared with the current implementation of boost::any? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Wed, Feb 9, 2011 at 1:07 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
What are your exception safety guarantees compared with the current implementation of boost::any?
I do not see the exception safety gurantees required of the held value object changing from the original any.hpp. I am using the placed new construction of course. Does it make any difference? -Adarsh Soodan
On Wed, Feb 9, 2011 at 1:24 PM, Adarsh Soodan <adarshsoodan@gmail.com>wrote:
I do not see the exception safety gurantees required of the held value object changing from the original any.hpp.
I am using the placed new construction of course. Does it make any difference?
Replying to self in bad form, but just realized the copy constructor of the held value object can cause inconsistent state. But it is fixable, so will commit the fix. -Adarsh Soodan
AMDG On 2/8/2011 11:54 PM, Adarsh Soodan wrote:
On Wed, Feb 9, 2011 at 1:07 PM, Nevin Liber<nevin@eviloverlord.com> wrote:
What are your exception safety guarantees compared with the current implementation of boost::any?
I do not see the exception safety gurantees required of the held value object changing from the original any.hpp.
What about swap? swap is no-throw now.
I am using the placed new construction of course. Does it make any difference?
In Christ, Steven Watanabe
At Wed, 09 Feb 2011 06:44:42 -0800, Steven Watanabe wrote:
AMDG
On 2/8/2011 11:54 PM, Adarsh Soodan wrote:
On Wed, Feb 9, 2011 at 1:07 PM, Nevin Liber<nevin@eviloverlord.com> wrote:
What are your exception safety guarantees compared with the current implementation of boost::any?
I do not see the exception safety gurantees required of the held value object changing from the original any.hpp.
What about swap? swap is no-throw now.
Just to be a little less opaque about this, everyone is asking because what you did is very similar to what's done in boost::variant, which led to some very interesting problems described in http://www.boost.org/doc/libs/1_45_0/doc/html/variant/design.html#variant.de... with very non-obvious solutions. So you might also consider what happens under assignment when the constructor of the new object throws. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Wed, Feb 9, 2011 at 9:44 PM, Dave Abrahams <dave@boostpro.com> wrote:
Just to be a little less opaque about this, everyone is asking because what you did is very similar to what's done in boost::variant, which led to some very interesting problems described in http://www.boost.org/doc/libs/1_45_0/doc/html/variant/design.html#variant.de... with very non-obvious solutions.
So you might also consider what happens under assignment when the constructor of the new object throws.
Thank you. I realize now that the code I posted will have to become comparatively a lot more complicated to replace boost::any in all situations. I will clean this up when time permits. I was curious if others have solved similar performance problems. I couldn't use boost::variant because I needed it for a message passing library where library user can pass in any message type. boost::variant would have been restrictive if the user wanted to use too many top level types of messages. - Adarsh Soodan
On Feb 9, 2011, at 12:38 PM, Adarsh Soodan wrote:
I was curious if others have solved similar performance problems. I couldn't use boost::variant because I needed it for a message passing library where library user can pass in any message type. boost::variant would have been restrictive if the user wanted to use too many top level types of messages.
I would be interested in having boost::any (or some variation on it) providing small buffer optimization. That was done for boost::function back around boost 1.34, and something like that would work just fine for my usage. I've given the SBO for boost::any problem a cursory look, but have not yet demonstrated a sufficiently bad performance problem for use there to convince my managers that I should work on that rather than something else.
On 9 Feb 2011, at 22:29, Kim Barrett wrote:
On Feb 9, 2011, at 12:38 PM, Adarsh Soodan wrote:
I was curious if others have solved similar performance problems. I couldn't use boost::variant because I needed it for a message passing library where library user can pass in any message type. boost::variant would have been restrictive if the user wanted to use too many top level types of messages.
I would be interested in having boost::any (or some variation on it) providing small buffer optimization. That was done for boost::function back around boost 1.34, and something like that would work just fine for my usage. I've given the SBO for boost::any problem a cursory look, but have not yet demonstrated a sufficiently bad performance problem for use there to convince my managers that I should work on that rather than something else.
I believe spirit/home/support/detail/hold_any.hpp contains something like boost::any, with a small buffer optimisation. This is not suitable for directly copying out into general boost. In particular I believe it assume any type held in the 'any' is streamable, and quite possibly doesn't consider issues of exception safety. On the subject of exception safety, I quite like how boost::variant will put a 'boost::blank' in (if that exists in the variant) if the value is lost. A similar 'empty' state for boost::any might solve problems with exception safety, at least for me. Chris
participants (5)
-
Adarsh Soodan -
Christopher Jefferson -
Dave Abrahams -
Kim Barrett -
Nevin Liber -
Steven Watanabe