Peter TB Brett writes: > [...] > > As a result it mostly moves the selection code from o_attrib.c to > > i_callbacks.c (where it is much more appropriate): where is the lot of > > code you see? > > Every invocation of those two functions has been replaced by an iteration > over > a GList.
These iterations previously were in the o_attrib_toggle_* functions. Only moved for the sake of imitating object methods. > > > 14/17 Replace TILE_LOC structure with list of references to TILEs. > > > > > > What, if any, effect does this have on performance? > > > > Obviously it reduces memory allocation: no more TILE_LOC, only > > reference to TILEs. Plus TILE_LOC added nothing that was not already > > in a TILE, plus it eases the access to the TILE (where the interesting > > things are)... > > > > Sure. My question was more about whether the TILE_LOC structure was > originally > there to increase speed (i.e. reduce the number of pointer dereferences by > one). Ales? A TILE_LOC contained indexes (i,j) for a tile in the page's array of TILEs (!). Removing the TILE_LOC avoid having to look for the tile that it referenced. Therefore increasing performance. Regards, Patrick _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
