Prerequisites tab performance

Blair,

My ongoing project that relies on a subclass of my view generator needed
some work.  The details are unimportant, but working on the generator means
that I get an explosion of new view resources, and it appears to be bringing
the status icons in the PB's prerequisites tab to a crawl.

Would it be reasonable to allow control over the aggressiveness of the PB's
search?  I _think_ that when I use the status icons, I'm looking for a
mis-packaged loose method or class.  I understand the need for
#hasCyclicPrequisites to search view resources, but suspect the PB status
icons would be well-served by an option to skip that search, at least for
many kinds of packaging problems.

BTW, I am running this on a ~2GHz P4 w/ win2k and plenty of RAM, so it's not
about horsepower.  As always, it is possible that I just clobbered something
and the performance is artificially poor as a result.  But based solely on
image size, and that the concern is not new, I doubt that is the problem.

One source of good news is that the recent generator changes have resulted
in different class names being generated, so some of the more expensive
views are "doubled" at present.  The older class names will eventually
disappear, which will reduce the cost of scanning the views.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:4035715d$[hidden email]...
> Blair,
>
> My ongoing project that relies on a subclass of my view generator needed
> some work.  The details are unimportant, but working on the generator
means
> that I get an explosion of new view resources, and it appears to be
bringing
> the status icons in the PB's prerequisites tab to a crawl.
>
> Would it be reasonable to allow control over the aggressiveness of the
PB's
> search?  I _think_ that when I use the status icons, I'm looking for a
> mis-packaged loose method or class.  I understand the need for
> #hasCyclicPrequisites to search view resources, but suspect the PB status
> icons would be well-served by an option to skip that search, at least for
> many kinds of packaging problems.
>...

Without searching all possible prerequisite sources the best one could say
would be either "no" this package is not saveable when the less diligent
search detected no problems, and "maybe" this package is saveable otherwise.
I don't think this would be useful myself because you aren't getting any
significantly more useful indication that all is well than having no
indication at all. Why not just turn off the icons (as they are by default),
and only enable them when you have a problem.

Regards

Blair

Blair,

> Without searching all possible prerequisite sources the best one could say
> would be either "no" this package is not saveable when the less diligent
> search detected no problems, and "maybe" this package is saveable
otherwise.
> I don't think this would be useful myself because you aren't getting any
> significantly more useful indication that all is well than having no
> indication at all.

I respectfully disagree.  Most of the packaging problems that I cause are
not related to resources.


> Why not just turn off the icons (as they are by default),
> and only enable them when you have a problem.

That's what I do, but the problem is that turning them on results in _very_
slow response.  Commenting out the the resource scan helped, hence my
suggestion.

Have a good one,

Bill

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