On Sunday, June 30, 2013 19:20:47 Steven Schveighoffer wrote: > On Sun, 30 Jun 2013 15:51:32 -0400, Jonathan M Davis <jmdavisp...@gmx.com> > > wrote: > > On Sunday, June 30, 2013 21:05:41 CJS wrote: > >> In the talk Andrei seems to mentions that D's associative arrays > >> are lacking in performance somehow. I'm very new to D, but it's > >> not obvious to me what the shortcoming is. I assume it's that for > >> some reason it's hard to specialize associative arrays to specfic > >> types to give increased performance in specfic cases, but I'm > >> unclear why that would be difficult. Could someone please > >> elaborate? > > > > There's one implementation, and you can't swap it out, whereas different > > use > > cases may perform better with different implementations. On top of that, > > the > > current implementation is rather buggy and fragile, but that's an > > implementation issue rather than an inherent one. > > No, the main issue is the current one is runtime-only, and so simple > function calls such as toHash and opCmp cannot be inlined.
Yeah. That's a big problem. We really need to templatize all that - though the current implementation is enough of a mess to make that difficult. > You absolutely can change implementations (Walter did a few years ago from > tree-based collision resolution to linked-list based). What you can't do > is switch to a fully generated AA, or change the compiler-expected API. Okay. I didn't know that. But I think that they key issue with swapping out the implementation is not whether you can swap out the implementation for your whole program but rather being able to choose different implementations for different parts of your program. If you really care about your containers enough to worry about optimizing them for your particular use cases, then unless you only have one use case within your program, there's a good chance that you're going to want different implementations for different parts of your program. With library containers, that's as simple as swapping which one you use. With the bulit-in stuff like AAs, you can't do that. You only get one (even if you can make it different across programs). Now, if you just use library types, you don't have that problem, so in the long run, folks who really want to optimize their containers will probably do that. And if they _really_ want to optimize their containers, they're probably writing them themselves anyway. Regardless, while having a built-in AA simplifies the common case, it _is_ more limiting, and if you really care about how your AAs function, you're going to have to use a library solution (even if the bult-in AAs have a solid implementation). - Jonathan M Davis