Mitch Harder (aka DontPanic) wrote:
> "#ifdef GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID" was not correctly
> recognized by my compiler.  It didn't throw out an error, my compiler
> just didn't see this as being defined.
 
> I am using gcc-4.2.4 and gtk+-2.12.10.  In this version of gtk-2,
> GTK_TREE_SORTABLE_UNSORTED_SORT_COLUMN_ID is part of an enum structure
> in gtktreesortable.h, and apparently not recognized by the
> preprocessor.  I had to employ: "#ifdef __GTK_TREE_SORTABLE_H__",
> which is the same #ifdef used in gtk's gtktreesortable.h file.

Thanks. Apparently this code was never active before because there were
also syntax errors. The point of the check was, that this enumerator
wasn't always available. I've changed it to check for Gtk+ >= 2.6.0
instead.

> First, I found that search stats processing is not performed when the
> search stats gui is not in focus.  This occasionally had the affect of
> accumulating a large backlog of search terms when the search stats
> page was finally brought back up, and gtk-gnutella was ignoring it's
> other duties for several seconds.
 
That was certainly not correct but the work for non-visible widgets
should be kept to a minimum. If you look at the other GUI code, you'll
see that they check for visibility in the periodic callback.  The
treeviews and stores should be frozen when a widget becomes invisible
and sorting should be disabled too because inserting items into a sorted
treestore is extremely slow.
 
> Second, I found you could still set the search stats parameters so as
> to accumulate so many terms that it could still run into problems with
> gtk-gnutella processing the stats.  So I built in some simple load
> evaluation code that would first disable sorting if more than 0.33
> seconds were required to process the stats, and would disable search
> stats altogether if more than 0.4 seconds were required to process
> even without sorting.

I reduced these limits. Frequent stalls of up to 300 ms just aren't
acceptable, especially not for such a gimmick. My main concern here is
that an average user might not realize the source of these stalls or
sluggishness and dismiss gtk-gnutella as a whole.

> It seems like the biggest usage of time is with building the gtk list.
>  The hash table is very fast, but it seems like there is still the
> potential for building a gtk list that is to large to process
> efficiently.

With the current code, the number of items grows indefinitely. So after
a couple of days or even just hours, performance becomes absolutely
unacceptable at least in ultrapeer mode.

For the moment, I've committed your patch to SVN but I might decide to
disable it again for the next release.

I don't know whether it's worth fixing these issues. Personally, I am
not interested which means I'm not going to fix them myself.  Patches
are welcome nonetheless.  For serious statistics, you would just log the
query strings and process them externally. Also there's so much
spam/crap in the queries, you're unlikely to extract much if any useful
information from them.

-- 
Christian

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to