Re: clist preformance

[Havoc Pennington <hp redhat com>]

Karl Nelson <kenelson@ece.ucdavis.edu> writes:
> 
> The best solution is just to rewrite all of clist to use 
> a binary tree as its storage type with a iterator like 
> Havoc is using for the Tk port.  Then looking up items
> in the tree would be order log N.  Iterating would be
> O(1).  It would still be slow to do massive changes but
> insertion would actually get faster.  (No order N for 
> middle insertions.)
> 

Even better is to make the tree widget a view that can be used to
display your already-existing application data structures; then make 
the tree representation or whatever a convenience thing for people who
want simple clist/ctree-style behavior. However anyone who wants real
efficiency can just avoid having to copy their data into the widget.

Any widget with serious efficiency concerns needs to avoid the design
where you have to copy your application data into the widget, and then
keep the widget's copy of the data in sync with your application's
master copy of the data. Not to mention that it's much easier to write
robust code without the synchronization issue, once you're doing
anything very complicated.

Havoc