Bill Baxter wrote:
[snip]
> Have you (or anyone) tested the performance of the tango containers? I'm 

Some tests were performed recently that indicate the HashMap is slower than AA for write, but significantly faster for read.

> concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).

Tango containers have opApply() on the container itself, so the heap iterators are purely optional.

Sean Kelly wrote:
> Bill Baxter wrote:
>>
>> Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).
> 
> I /really/ want a chance to work on containers someday soon, but I'd like to preserve the interface aspect for a few reasons:
> 
> * It makes the Tango implementation a framework to build on rather than a reference set of containers.
> * Following from the previous point, it separates the container library interface from its implementation.
> * It allows for Java-style (ie. runtime) container access as well as C++-style (ie. template-oriented) container access.

But it does it allow the C++-style currently? It seems like currently the containers themselves have access to a way to instantiate a concrete iterator and bypassing the interfaces, but not the outside world. There's no generic alias for a containers concrete iterator type, for instance, and no function that returns an object of the actual concrete type rather than an interface pointer.  At least I didn't notice any.


> If structs are used as iterators there would be no way to prevent their being copied, and some things which could be described as iterators should not really be copyable (input iterators, ODBC cursors, etc). 

I think D2.0 is going to give you a way to have some code run after the element-wise copy, so you could throw an exception there for the iterators that shouldn't be copyable.  Maybe even a static assert.  But that's not much help today.

> Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive.  I would be interested to hear opinions on performance requirements related to this.

Don't your iterators already have interfaces?
You must mean something different from what I think you mean.


--bb

Bill Baxter wrote:
> Sean Kelly wrote:
>> Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive.  I would be interested to hear opinions on performance requirements related to this.
> 
> Don't your iterators already have interfaces?
> You must mean something different from what I think you mean.

I mean a future, theoretical implementation.  Aside from some D-ification about a year ago, we really haven't spent much time on tango.util.container beyond the original port from Java.


Sean