On Tue, 2004-01-27 at 07:23, Raphael Manfredi wrote: > I would prefer a patch that would use a '#' stored somewhere else than > in the record, with clear commenting about why it is done that way. >
When a search response is returned we create a search record for it. The GUI uses this record for all the sorting, manipulation, etc. that it does (this was what we did before I added grouping). When I had the need to add a count column I was like "I need to keep track of a value for every single search result returned". Well, this is exactly what we were using the result struct for so I just added another value to it. The thing I overlooked was that passive searches don't create their own search results records, they just piggy back on the ones created by other searches, which makes sense structurally. Another way to look at it is that the "Count" value is purely a GUI value and doesn't necessarily represent the result data across the whole scope of the program and so doesn't belong where I put it. So, probably the best solution is to create another list of structures to hold info only need by the GUI for each search. This will include "filename", "host", etc. thereby also cleaning up the double usage of the search results records we were doing before. ie. The "GUI" will only worry about and manipulate the gui records and the core can worry about manipulating the search result records. The only disadvantage to this is a bunch of duplicated values between the search result records and the new "gui" search result records which means increased memory usage. If you want me to implement this, say the word (I am assuming yes, but don't want to get hacking if y'all think I'm out to lunch). > Can you explain why performance is lower when '#' is stored in the GUI > instead of in the record? Does the problem exist in GTK1 only, or does > it apply for GTK2 (I would assume the latter). > This doesn't apply to GTK2 because Treeviews handle their data and sorting much differently (I think in a much better fashion). The performance is lower in grabbing the text from a column because instead of just referencing a integer we have to get the text string out of the column, do some strcmp checks, convert it to an int, do a number of int compares and return the result. These aren't heavy operations and only increase the complexity by a constant value, but the increase is for every compare and the increased lag is noticeable. As I said, it's not super drastic but it's there. (If you apply the patch I sent, sort a maxed out passive search by # and then sort a maxed out regular search by #, you'll notice the difference but likely agree it's acceptable if that's what we have to do). > I don't really mind if it's slower because the current behaviour is > not correct. You can make any program fast when you sacrifice correctness! Yeah totally. However, for the record, the patch I sent makes the current behaviour correct. The only issue (I see) is making the code less confusing, which is obviously important and I think both issues will be addressed by adding the gui search result struct mentioned above. Emile ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
