Finding cycles

Hi Blair,

I'm finding that the effort to track down the cause of cyclic prerequisites
has increased due to the larger number of packages.  Looking at the
prerequisites tree though, there might be an answer: how hard would it be to
filter it so that it shows only the branches that "wrap around"?  I think
it's worth some attention (even if only for an early patch level) because
the Dolphin newbie will be faced with a large number of packages out of the
box; their first cycle will be a nightmare to find =:0

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

I found it - testing methods (one of these days I'll wise up and start
looking there<g>).  Actually, the CompositePresenter/loose method thing had
a hand in it too, but, that's fixed.

The prerequisites display is quite sluggish.  I'm working on a not-too-bad
P3 at the moment, and it struggles to redraw the tree; worse, it struggles
to redraw the tree every time it's scrolled.  It could just be the larger
number of packages as you suggested before.  Is there any performance hit
due to its being embedded in the PB?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> The prerequisites display is quite sluggish.  I'm working on a not-too-bad
> P3 at the moment, and it struggles to redraw the tree; worse, it struggles
> to redraw the tree every time it's scrolled.  It could just be the larger
> number of packages as you suggested before.  Is there any performance hit
> due to its being embedded in the PB?

Looking at the pre-req display on a rather slow P2-333, it is by no stretch
of the imagination "sluggish" at drawing the tree without the status icons
turned on. Ok, it is noticeably slower with the status icons but, frankly,
hardly sluggish. And this is with a machine that should be significantly
slower than any P3. In any case, I can't help but feeling you are being
unduly negative here; why is it important for most people's development to
scroll this display more quickly. How long do you think we should delay the
release to investigate this?

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk Wiki Web
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Andy,

> > The prerequisites display is quite sluggish.  I'm working on a
not-too-bad
> > P3 at the moment, and it struggles to redraw the tree; worse, it
struggles
> > to redraw the tree every time it's scrolled.  It could just be the
larger
> > number of packages as you suggested before.  Is there any performance
hit
> > due to its being embedded in the PB?
>
> Looking at the pre-req display on a rather slow P2-333, it is by no
stretch
> of the imagination "sluggish" at drawing the tree without the status icons
> turned on. Ok, it is noticeably slower with the status icons

Thanks for reminding me of that - I think they are off, but, maybe they are
being calculated but not displaying for some reason.


>  but, frankly,
> hardly sluggish. And this is with a machine that should be significantly
> slower than any P3. In any case, I can't help but feeling you are being
> unduly negative here;

No - I'm being honest about how I think the majority of your customers will
react; I appologize if that offends you.


> why is it important for most people's development to
> scroll this display more quickly.

I think it's reasonably safe to label me as an "expert" re Dolphin.  I had
to track down a relatively simple cycle, and found it daunting in part
because of the large number of branches in the Dolphin tree (which was
involved at one point because of an errantly placed loose method),  The
large number of branches causes another problem: it forces one to open/close
branches and scroll often.  Every time I touched that scroll bar, I saw
another round of noticiable redraw.  I'm a litle tight on time right now,
but, hopefully I'll have time to check the performance on my 1.8GHz P4.
Later in the day, I'll look at the status icons isse.  As I said, I don't
see them, but they might be being computed.


> How long do you think we should delay the
> release to investigate this?

I didn't say you should.  If it turns out that the status icons are being
computed but are not being displayed, I would advise you to fix that, of
only by having the setting turned off.  More to come.

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

I don't know if this has any bearing on the matter, but it reminded me of
something I saw looking through the Education Centre.  In searching for
"win32 AND structure", one of the topics listed was "untitled" -- clicking
on that brought up a slow slow (drawing and scrolling) tree.  The URL in my
local chm file is
mk:@MSITStore:C:\Dolphin4\EducationCentre\EducationCentre.chm::/EducationCen
tre.hhc.

I realize this is not a Dolphin app, but perhaps it points to an MS Treeview
bug surfacing.

Andy,

> Looking at the pre-req display on a rather slow P2-333, it is by no
stretch
> of the imagination "sluggish" at drawing the tree without the status icons
> turned on. Ok, it is noticeably slower with the status icons but, frankly,
> hardly sluggish. And this is with a machine that should be significantly
> slower than any P3. In any case, I can't help but feeling you are being
> unduly negative here; why is it important for most people's development to
> scroll this display more quickly. How long do you think we should delay
the
> release to investigate this?

The PB appears to be slightly mis-configured.  It has a block to generate
icons that are, by default, not displayed.  My recommendation is to either
nil out the block (and IIRC one other item mentioned in an earlier post, the
relevance of which I now understand), or arrange for the icons to be
displayed.  The latter is probably prefereable.

Interestingly, the performance degredation is conditional and can be quite
severe, most likely in proportion to the complexity of the cycle.  It
appears that a "healthy" image, won't exhibit the problem.

In my recent cycle search, the icons probably would have been helpful, and
any performance hit would have been more than justified if they showed which
branches to investigate.  As shipped though, it appears that one pays the
overhead and doesn't get the benefit.

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Bill,

> If it turns out that the status icons are being
> computed but are not being displayed,

I found this to be the case by setting the getImageBlock to nil. Blair
recorded it as #875, a bug in TreeView.

Thanks,
Steve

Steve,

> > If it turns out that the status icons are being
> > computed but are not being displayed,
>
> I found this to be the case by setting the getImageBlock to nil. Blair
> recorded it as #875, a bug in TreeView.

Maybe the answer is to modify the block to invoke a (probably class-side)
method that can conditionally do the heavy computing.  When the ok/problem
icons are not needed, it could answer a "don't know" (square, question mark,
etc.) icon.  I **think** that would be fast enough for most purposes, even
with the view in small-icons mode, and would allow one option to control the
behavior w/o having to modify the view resource.  Comments?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Louis,
> I don't know if this has any bearing on the matter, but it reminded me of
> something I saw looking through the Education Centre.  In searching for
> "win32 AND structure", one of the topics listed was "untitled" -- clicking
> on that brought up a slow slow (drawing and scrolling) tree.

Yes, I get that too.  Very odd.

    -- chris