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@puremagic.com <mailto:digitalmars-d@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
