[gpodder-devel] Gpodder is slow / comments on bug #59
- From: alistair.sutton at gmail.com (Alistair Sutton)
- Date: Thu, 24 Apr 2008 10:44:48 +0100
2008/4/24 Thomas Perl <thp at perli.net>:
> Hello!
>
> On Wed, 23 Apr 2008, Alistair Sutton wrote:
> > 2008/4/23 Nick Nobody <me at nikosapi.org>:
> > > If you've got some time you could try playing with python's
> > > built in profiler[1] to see what's causing the slowdowns. Sorry,
> > > I don't have too much time on my hands,
> >
> > I'll have a look and see if I can dig anything up.
>
> Yes, it'd be nice to see some results from a profiler run.
> You can also use the logging facility to come up with some
> time measurements for operation durations.
I didn't have much time to get my head around the profiling however I was
watching the logging gpodder does on the console.
There was a massive pause of around 2/3 minutes at some point during the
console output.
What I noticed was that I was getting quite a few messages about pubDates
being identical. I had a very quick dig around in the code and added a
couple of log statements in order to print out the name of the rss feed that
(presumably) was being parsed in order to generate these messages.
I narrowed the biggest pause down to a Sun Microsystems custom-generated
feed which was being limited to 200 entries, had only one entry being
registered as "new" and the rest were in a seemingly "unknown" state (i.e.
not marked as new, not marked as deleted etc). Downloading the oldest
podcast in the feed then automatically marked everything else as new and
not-downloaded.
Gpodder instantly became a lot more responsive. There is still a lag of
maybe 30 seconds or so between starting the download of a podcast and the
GUI updating to recognise this, but it doesn't seem to be anywhere near as
bad as before.
One thing that I have noticed from the digging was that gpodder seems to
want to scan/sort all the feeds and episodes every time something is
downloaded (I'm assuming this from the fact the messages are always very
similar regarding identical pubDates). Is this the case and if so, would it
be easy/possible to cut down on the amount of feed scanning/sorting that
takes place?
I get the impression that if it was possible to only scan/update the feeds
that have just had items downloaded then gpodder would be amazingly fast
(even with an insane amout of items in the feed like mine!)
I'll do some more digging around when I get home from work to see if the
problem really has gone or if it can still be improved.
Hope all the above makes sense!
Alistair
--
WWW: http://ajs.no-dns-yet.org.uk
GPG/PGP: http://ajs.no-dns-yet.org.uk/pubkey.gpg
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.berlios.de/pipermail/gpodder-devel/attachments/20080424/21a54301/attachment.html>
Other related posts:
