gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: Gump3 inter-component orchestration/communications
Date Wed, 13 Apr 2005 08:06:34 GMT
On 12-04-2005 22:35, "Adam R. B. Jack" <> wrote:
>> Do you think we could do without multiple stages completely?
> I think it just comes down to order. The "walker logic" I've preferred most
> is the one that iterates through projects, visiting modules (and
> repositiories and workspaces, etc.) on demand (for those projects) and
> visiting each plug-in in sequence.

Yeah, that "just works". I kept that intact AFAICS :-D

> A sequence of (1) start time stamp (2)
> build (3) end time stamp (4) DB update (5) notify -- seems fine w/o need for
> pre or post processing. So, I guess (as of my view right now) "yes, maybe".


>> I've always found it really annoying to want to debug something and
>> then seeing that a build is "in progress" meaning part of that tree is from
>> the run before and part of it is new. Very confusing...
> Yup, agreed, but that is something I hope we can fix with the Gump3
> separation of run from presentation,


> This all said, I'm in no hurry to redesign things and remove the three
> phase, I was just wondering. Time will tell.

Heh. You're entitled to an opinion dude! If it bugs you, it's about 10 lines
of code, just go friggin' make the change ;)

> BTW: One last thought .... property bloat leading to memory bloat. I've
> found with Python (for Gump2) that object/property bloat can really clog
> things up. Sure, a lot of it was the DOM tree (and those are being pruned)
> but I do think we'll hit this later, with full runs. I'm not saying we ought
> think about this now (I just have scars from months of fighting performance,
> so can't forget) but we might want some sort of Reaper plug-in that keeps us
> lean. That'd need to run after all plug-ins for a project. Again, time will
> tell...

I've run some tests on that. I'm not too worried. The main problem with the
DOM stuff is that you get massive amounts of circular references so none of
it is cleaned up until you unlink(), and DOM stuff really does get massive
quite quickly.

Combining then discarding all parts of the DOM asap and transforming it into
something much more lightweight with weakreferences in strategic locations
should pretty much alleviate our concerns at first; python doesn't have
/that/ much overhead for simple objects.

If we get memory issues, well, we'll be using a database quite a bit, and we
can store things like build logs (lots of text) in there directly then add a
get_build_log() method instead of property that runs the SQL bit. Or we put
it on the filesystem.

IOW I'm not worried, lets not optimize prematurely :-D



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message