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. _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
