Decision on container design

[dsimcha]

BTW, I thought the case for a sealed hash table with an optimized memory 
allocation scheme was self-evident to most heavy D users, given how the 
builtin hash table leaks memory/fragments the heap (I think it's a 
little of both) and destroys multithreaded performance.

On 2/1/2011 11:00 AM, Andrei Alexandrescu wrote:
> On 1/29/11 3:36 PM, dsimcha wrote:
>> I've uploaded the documentation to
>> http://cis.jhu.edu/~dsimcha/randaasealed.html and mentioned it again on
>> the mailing list. The documentation is pretty sparse because
>> interface-wise it's just a standard hash table. More generally, though,
>> are we still interested in sealed/ref counted containers?
>
> Sorry for being slow in continuing this thread.
>
> Regarding the general issue that someone makes an informal proposal
> (either here, as a DIP, or on the Phobos mailing list), followed by a
> thundering silence: I believe that a good technique is to formalize the
> proposal review process, which has been a homerun for Boost. The
> disadvantage of that is that almost without exception this is very
> taxing to library submitters. This means the submitter must put a lot of
> thought and a lot of work into motivating, polishing, and documenting an
> artifact without any guarantee that it would lead to inclusion in the
> target library. I've seen very, VERY elaborate Boost submissions fail -
> literally months of work gone to waste.
>
> I'm not sure how to save people from doing work up front in hope of an
> uncertain outcome in the future.
>
> I do know what does _not_ work: the take it or leave it approach: "Hey,
> I have this code for abstraction XYZ that I extracted from a project of
> mine and I think it may be of general interest. It's at
> http://site.com/path/to/code.{d,html}. It needs polishing here and
> there, it's largely undocumented, but I'm sure the ideas shine through.
> Eh?"
>
> The doc at http://cis.jhu.edu/~dsimcha/randaasealed.html is somewhere in
> between. It is clear you have a good understanding of sealing and hash
> containers, but let me ask you this - if you wanted to sell this to
> someone, what would you do? Probably you'd show some relevant benchmarks
> putting the built-in hashes to shame. Maybe you'd have some good
> examples - yes, we know it's a hash, but it doesn't hurt to see some
> code pulp over there. Maybe you'd explain sealing and discuss its
> relative advantages and disadvantages (which have not yet been
> documented anywhere - a great opportunity). Maybe you'd even show some
> numbers showing how sealing does as well/better/worse than reference
> leaking.
>
> This is a good amount of upfront work for little promise. Again, I don't
> know yet how to optimize for minimizing that. What I did see works on
> Boost is a request for interest in the form of a discussion (usually
> with NO source, only USAGE examples) asking if there are people who are
> interested in such a notion. In this particular case, you'd need numbers
> to make a strong case which means that code must be already written. For
> something like e.g. "how about a Finite State Automaton library?"
> perhaps upfront code wouldn't be necessary for gauging interest.
>
>
> Andrei
>