Re: [boost] [poly_collection] Memory allocation and allocator propagation

Subject: Re: [boost] [poly_collection] Memory allocation and allocator propagation
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-05-16 07:23:52

El 16/05/2017 a las 1:00, Ion Gaztañaga escribió:
> [discussion about avoiding unique_ptr in segment_backend and scoped 
> allocators]

I'll definitely try to implement this along your suggestions --might 
need your
offlist help, though :-)

>>> - The "emplace" operation uses a placement new to wrapped in a lambda
>>> which is type-erased with a captureless lambda. It looks to me that
>>> instead of delegating the work into the value_holder, the type erasure
>>> arguments should be treated by the segment so that internal vectors
>>> propagate the allocator when needed.
>>
>> I don't see how this could be done: type erasure must happen before
>> segment is used, and actual
>> args types are then unknown to segment... Care to elaborate?
>
> I haven't thought it carefully and it might not possible at all, but 
> maybe the lambda could execute:
>
>    s.emplace_back(forward<Args>(args...));
>
> where s is the concrete segment type that can be obtained via Model 
> (the address of the aligned storage inside "class storage" is casted 
> to Mode::get_segment_type<T>::type*) because the ConcreteType we are 
> going to construct is known at compile time in emplace_back_impl.
>
> I also wonder if insert<T> and other functions should avoid slicing 
> detection so that they can also avoid the virtual call overhead. If T 
> is assumed to be the same type of the final ConcreteType, you can use 
> typeid(T) instead of typeid (x) (which can require to trip through the 
> vptr) when searching in the unordered map and obtain a pointer to the 
> concrete segment type just casting. Insertion times could be improved, 
> specially range insertions could shine (as vector could be resized 
> just once). Or am I missing something? 

Ion, I think you're on to something here. As it happens, poly_collection 
can
statically determine when T is acceptable and dynamically detect the cases
where x's subtype is actually T, in which case virtual calls can be omitted
altogether --A reference to the internal 
packed_segment/split_segment<Model,T,Allocator>
can be statically obtained from segment<Model,Allocator>. I have to 
think this
carefully, but this can be huge in terms of insertion performance. 
There's no need
to dispense with slicing detection.

Joaquín M López Muñoz