> The cycle time between updates of the web site was around 9 hours - gump
> was reporting about 5 hours for the run (so we are already seeing a big
> improvement on that aspect). In addition there is that mystery 4 hours
> between the end of the run and the appearance off documentation.
Not really, much of the leakage of memory (and hence the slow down) was the
web page generation. We still have some of that, but things are better. Now
the pages that are listed in the buildLog.html (updated every 5 projects or
so) is new. We (sub-optimally) redo the pages in a batch run at the end (so
we can document dependendees and such) but I'll whittle that down over time.
> > Still, it can do far far better. Multi-threading the CVS/SVN ought
reduce
> > the latency. The main problem (for no clear reason I can gather) still
seems
> > to be generating documentation.
>
> Just an observation - that way things are using the current setup is
> "for me" better. Ok the docs are not a nice but what I can see
> immediately is the following:
>
> (a) a message saying "gump is running and it started at ..."
> (b) result as they unfold which gives me more time to hit the
> issue (e.g. I figure I've fixed james during the last run
> because I was able to access the info before the run had
> completed)
Yup, and one ought now get an e-mail notification at this point also (for
first time failures/state changes).
> Things I wasn't too impressed with was the dirty big red banner
> complaining about my subversion of build.sysclasspath which kind of made
> me cringe.
>
> :-)
Hey, I spent so long on having Gump use Forrest 'cos I'm no GUI guy. The
style sheet is here, feel free to help me fix it:
http://cvs.apache.org/viewcvs.cgi/gump/template/xhtml/css/style.css
>
> > Ever tried a targeted run?
>
> Nope - never.
> I'll leave that sort of thing to Niclas!
>
> > If one runs to (say) depot or something like this
> > (a trimmed stack), this thing flies. It is something that clogs up over
time
> > & I can't track it down (ok, haven't yet).
>
> Watching the interactive progress you get a feel for this as well - gump
> kicks off and rips though the early entries but things get progressively
> slower. But the end of the run she's not showing the same degree
> enthusiasm!
Yup. We have 50 Mb (crazy I know, but it is 100K a project) of XML/DOM/model
in memory, and we seem to start off fine. We creep that up to 75 Mb and we
slow to a crawl. I don't think it is (exactly) the memory tree (although we
do keep adding to it, e.g. with results of executed commands) but something
is such clogging up. The page generation (DOM-like, and not a favourite of
many here) starts fast but ends slow, when there ought be no difference.
Hmm -- sometime I wonder if I ought turn off the garbage collector, or try
some optimizations. I keep meaning to seeif I can cope w/ comp.lang.python,
but I doubt I can w/ my network bandwidth.
Q: Has anybody thought of an ASF developers python mailing list? Just for
folks working in Python for ASF, be it MoinMoin extensions, or Gump, or ...
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
