30 Jul
2007
30 Jul
'07
2:18 p.m.
> I'm not sure I see what's the performance problem with this type, but I'm > curious, so could you elaborate a bit ? :) > If you see a better way that would also clean up the code, it could be > interesting. Hi! 1. Almost all alpm functions need a list of pmpkg_ts; and the pmpkg_t <-> pmsyncpkg_t conversion is costly (see _alpm_sync_prepare: after topo sorting the list, you need to do an O(n^2) conversion); a kernel list-like implemetation would be more efficient (or merging pmsyncpkt_t to pmpkg_t) 2. The implementation of replaces is very ugly. 3. alpm_sync_free doesn't free (or what is FREE?!) the pkg member of spkg struct, however other parts of the code assume that it does it: huge memleak (?!) 4. in more general: this pmpkg_t of alpm_list implementation is not efficient, internally graph-like structures would be better, now you need to do at least O (n) computation to find the "edges" (and we should do this only once) etc. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/