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
