gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: [RT] Gump[y] internals re-design
Date Fri, 14 May 2004 14:08:10 GMT
BTW: If we used the statistics values (namely, duration in state & last
state) we could intelligently notify [only first time, only when changed
from success to failure, when 'fixed'] and hence notify any time a run
occurs. [If we get rid of the Forrest run, which we can as soon as the
Forrest webapp is install on Brutus I suspect we could get 12-24 runs a day,
if not more.]

This (I feel) would really open up Brutus' power, significant reduce the
debug window [working well for projects with folks in various timezones],
and hence allow the 'projects to be aligned.

regards

Adam
----- Original Message ----- 
From: "Adam R. B. Jack" <ajack@trysybase.com>
To: "Gump code and data" <general@gump.apache.org>
Sent: Friday, May 14, 2004 6:39 AM
Subject: Re: [RT] Gump[y] internals re-design


> From: "Sam Ruby" <rubys@apache.org> wrote:
>
> > Adam R. B. Jack wrote:
> >
> > > (it is slow to load 600 projects)
> >
> > why?
>
> Funny you should ask, it oughtn't be. Simple answer, I don't know.
>
> I've had suspicions, I've even did a quick performance analysis (distance
> past), but I've never been able to track it down. I know that in the early
> days of Gumpy, Nicola would enjoy how fast it was to load metadata, but
the
> trouble was that was from a local cache of the HTTP|viewcvs files (it did
> not check with the original source, if the metadata had changed).
>
> I wondered if it was the fact that I was mapping the raw XML metadata over
> to some peer objects, but when I did an analysis I didn't think that was
> expensive. I did some profiling,
>
>     #print 'Profiling....'
>     #import profile
>     #profile.run('irun()', 'iprof')
>     irun()
>
> and found inordinately high numbers of some dictionary related method down
> in the XML classes, but got out of my depth at that point.
>
> I would really appreciate some assistence with debuggin that, 'cos I know
it
> wasn't originally felt to be expensive & would like to see it return to
> that.
>
> regards
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message