Re: [Evolution-hackers] interesting code ...

[Not Zed <notzed ximian com>]

On Wed, 2005-06-29 at 19:02 +0530, Parthasarathi Susarla wrote:
> Hi michael,
> Thanks for the 'review' of the groupwise code, and ofcourse for pointing
> out the _very_ obvious mistakes in the code.
> 
> 
> On Sat, 2005-06-18 at 03:52 +0800, Not Zed wrote:
> > Or at least ... interesting choice of algorithms.  I sure hope this
> > isn't called very often?
> > 
> > 2 N^2 loops ... AND it accesses data AFTER it is all freed (the uid's
> > are no longer reffed after you free the objects which hold them, it just
> > happens that because of other reasons this will usually work).
> > I gotta say the whole gw code looks mighty odd, whomever wrote it
> > obviously loved using singly linked lists - about the most inefficient
> > choice imaginable in this case, particularly given the data in question
> > is already in an array in all the cases i've seen (these two below are
> > more than enough for now, thank-you-very-much).
> For now i will continue using GSList, since switching to GList would
> require a huge amount of code change, both in groupwise backend and the
> provider itself. 

Many places - those i pointed out - use lists to redundently copy
arrays.  As far as i could tell the lists had no other purpose, and in
some cases, no purpose at all.

> I also should add that am a little stuck here. Having 2 pointer
> arrays/lists, what would be the best way to check if data in
> 'ptr-array/list A' is also present in 'ptr-array/list B'?  

Depends on if they're sorted or not.  If they are sorted you can do a
single-pass incremental set operation (union/intersection/etc).  If not
you can either sort them, or use a hashtable.  Sorting an array is more
efficient than sorting a list.

All of the 'list of messages' related code in the disksummary branch
enforces sorted iterators or arrays.  One reason is to simplify the
code, but the main reason is to improve locality of reference - the
items are being loaded from disk so it is far more efficient if they are
accessed incrementally in order.

Depending on the lifecycle of that branch vs the main line, this code
will need a massive 'clean up' (read: rewrite) anyway; so i suppose
there is no rush.

I'm just a bit concerned about the quality of the groupwise code
overall.