Arc.Tango

[redsea]

C++ STL's qsort is much faster than C's, because C's implemement need a function call, a function not only need more CPU instructions, but effect the pipeline, prefech subsystem and cache.

So if a iterator is implement with interface, I would not us it when I need high performance, it would a pain when I need to write complex datastructure.

I sugesst you can consider implement an inner iterator as structure, but wrap it with a class for daily use, when one need high performance, he can switch to the raw high performance version.
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.
> 
> 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). 
> 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.
> 
> 
> Sean