An important pull request: accessing shared affix for immutable data

[Andrei Alexandrescu via Digitalmars-d]

On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote:
> 2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>>:
>
>     https://github.com/D-Programming-Language/phobos/pull/3991
>
>     The only difference between an approach based on an associative
>     array and AffixAllocator is that the latter is faster (the
>     association is fixed by layout).
>
>
> Could you point to your benchmark / paper about this ?

There's no need. I'll do the implementation with the prefix, and if you 
do it with a global hashtable within the same or better speed, my hat is 
off to you.

> The general idea sounds good, however I share deadalnix's concern over
> storing the metadata next to the user's data. I also fail to see how
> those are a "soup of generic considerations", given it only apply when
> using an affix.

It's really easy to throw hypotheticals out and speculate what's going 
to cause slowdown and what's not (and look awfully expert in the 
process). I'm very familiar with the concerns guarding storing metadata 
in jemalloc seeing I've worked in team with Jason Evans for months; most 
are quoted from rote and don't apply here.

But the entire matter of digging down into how efficient the layout is 
would be a massive missing of the point. AffixAllocator is one example, 
there are many other tactical possibilities for allocators to stash 
metadata, neither of which affects the point.

The point here was safely getting to modifiable metadata for modifiable 
data. Timon Gehr was the one person who figured the real problem 
(inadvertent sharing of data not meant to be shared). I think I'll 
remove the const overload for now. Would that leave any hole unplugged?


Andrei