2 ms·
> This is horrible advice. There's a reason that you don't write your own hashtable implementations. Of course you do and release(d) them as open source (publi
by xxs 6y ago
> This is horrible advice. There's a reason that you don't write your own hashtable implementations.
Of course you do and release(d) them as open source (public domain). Take Java - it has decent a HashMap but it's node based. It's memory inefficient to a point its nodes and arrays are top 3 of memory consumption. An array based hashtable takes around 3.6 times less memory for larger ones (on 4bytes compressed pointers) and over 10 times less for smaller ones. Perf. wise it's on par or better as well (nowadays architecture is heavily driven by locality and access patterns)
Also you make your code so it can switch between both on the fly, if need be.
- yoz-y 6y ago> Of course you do and release(d) them as open source (public domain). How ironic though. Of course it did work a few times, but if the advice is to not use dependencies, then the better advice would be to not use dependencies that were written in an afternoon to avoid using some other dependency :)
- xxs 6y ago>How ironic though. Indeed! Although I spent like a weekend to do it (the inital release was 512 loc). It passed all standard jdk/jsr-166 Map tests[0] and then some more, incl. perf., memory consumption, garbage collection harness. Tests are also public domain. Also the release is not available as dependency, so the interested user would have to clone the repository on their right own. The part with afternoon deps would be that all their code can be read and cloned, if need be. Free to pick the few functions needed - I'd assume around 200-400 loc top. [0] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/ http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test...