On Mon, Jun 09, 2003 at 05:17:23AM +0100, Tim-Philipp Muller wrote:
> > Does the core pass the gaps unsorted at times?
> I don't know, to be honest. It _should_ not, and last time I've checked, it
> did not. But that doesn't mean it doesn't happen, and it might also be
> version-dependent. I would not want to rely on the gaps being in the right
Okay. It would actually make sense that the core doesn't, so the front-end can
worry about sorting it, freeing the core's cpu time to stuff like hashing files
when a new one is shared out. :-)
> > If so, are the gaps always of equal size, including the trailing
> > gap?
> What exactly do you mean here? If you mean each gap _record_, then the answer
> is yes (4 bytes start + 4 bytes end + 2 bytes status). If you mean whether
> (end-start) is always the same value, then the answer is no.
The latter. Darn. So much for the performance hack.
> > Speed-wise, the downloads page's stats creation is the worst offendor for
> > performance from my limited profiling.
> yes, I can confirm that. I am not quite sure what exactly causes the bad
> performance though. Either
> (a) there is a bug somewhere that either (aa) causes the gaplists to be
> requested far more often than necessary (e.g. every 3 secs instead of
> every 15-30 secs), or (ab) causes the gaplists to be made into a
> pixmap far more often than necessary (e.g. even though we already
> have a gaplist/pixmap, and the list hasn't changed in the meantime)
I noticed the gaplist was requested even when there was no status change, when
I did a bit of printf()-based "profiling" (the gcc -pg stuff was less than
useful due to the call-back based nature of the program). It also seemed to
request it every few seconds, about 2~3 seconds, I think.
Don't know about pixmap generation.
> (b) the pixmap plotting itself is horribly slow (note: in the 0.5.0 GUI the
> progress bars were first created as an XPM image in memory, and then
> transformed into a bitmap/pixmap in one go from the XPM, but this
> seemed rather clumsy to me, so I've changed the routines to directly
> draw on an image now. Maybe I'm using the wrong widget or routines
> though :-/
I'm not really familiar with GUI programming (as you can tell :), but does a
facility exist where one can say, create a line, set the color of pixels, then
tell X (or the library), "Here's a rectangular region, upper-left and lower-right
coordinates are (x0, y0), (x1, y0). Tile this image onto the region:
(x0, y0), (x1, y0 - z)."?
> (c) there is some other thing going on that I am not yet aware of :-)
Hmm... could also be network overhead. I'm almost always running the client
over an ssh-forwarded X connection. Does the gaplist get sent as a big cunk
of data, or as many tiny packets?
> I've recently (couple of weeks ago) changed the gaps request routines so that
> not all gaps from downloads that need updating are requested at the same
> time, but are spread out over a couple of seconds with a random(-ish) delay
> to 'spread' out the cpu usage of creating the pixmaps a bit over time and
> avoid cpu spikes. I'm not entirely sure yet whether this was a good idea or
> not. It doesn't show any adverse effect on my box, so I left it for now.
I usually want to see the list just to have a quick look at the progress of
downoads before iconifying the window and working on something else, so what
about a "don't bother upating until the user's viewing" option?
> But the whole progressbar/gap thing is definitively something worth
> investigating. Unfortunately my profiling results are not really too
> detailed, so I am not sure where the bottleneck really is. I somehow cannot
> believe that it's in the sorting. Even an old CPU can sort a couple of
> hundred gaplists with 10-100 gaps or so each in a matter of millisecs, I
> would suppose.
I don't think the sorting is the bottleneck, but sorting algorithms are
something I'm comfortable with, which is the reason for my questions. :-)
> Any further ideas/comments/thoughts?
Yup. Welcome back from vacation. :)