adobe-source-devel

[Adobe-source-devel] any_regular_t and capacity

[Florin T. <fl...@gm...>]

Hello,

I know any_regular_t has in-object allocation for types smaller than 8 bytes
(64 bits). Larger types are allocated on the heap. Consider this scenario:

BigObject obj; // 56 bytes->heap
any_regular_t value(obj);
[...]
SmallerObject obj2; // 24 bytes
value.assign(obj2); // destroys current object and re-allocates

I looked at how any_regular_t::assign is implemented and it tries to
preserve its capacity if the new type is the same as the existing one. If
not, it destroys the guts of the current object and re-allocates.

Since heap allocations are expensive and a major bottleneck for scalability
I was wondering if anybody considered worth implementing an optimization
that checks if the current capacity is enough when re-assigning. A reserve()
and clear() methods would be a nice bonus.

Best regards,

Florin

Re: [Adobe-source-devel] any_regular_t and capacity

[Sean P. <sea...@ma...>]

I don't think anyone has looked into this - you could do this in the  
case the new type is smaller - if you want to go back up then you  
would also need to store the size and that would break ABI  
compaticility (you'd need a version_2 any_regular_t...).

I think reserve() would be tricky because of the small object  
optimization and ABI compatibility. Most of the cases I dealt with  
were small objects (dictionary, adobe::vector, string_t, basic  
types...). Being a small object is one advantage adobe::vector has  
over std::vector.

Sean


On Jan 20, 2010, at 3:15 PM, Florin Trofin wrote:

> Hello,
>
> I know any_regular_t has in-object allocation for types smaller than  
> 8 bytes (64 bits). Larger types are allocated on the heap. Consider  
> this scenario:
>
> BigObject obj; // 56 bytes->heap
> any_regular_t value(obj);
> [...]
> SmallerObject obj2; // 24 bytes
> value.assign(obj2); // destroys current object and re-allocates
>
> I looked at how any_regular_t::assign is implemented and it tries to  
> preserve its capacity if the new type is the same as the existing  
> one. If not, it destroys the guts of the current object and re- 
> allocates.
>
> Since heap allocations are expensive and a major bottleneck for  
> scalability I was wondering if anybody considered worth implementing  
> an optimization that checks if the current capacity is enough when  
> re-assigning. A reserve() and clear() methods would be a nice bonus.
>
> Best regards,
>
> Florin
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel