I've noticed some things in the Settings area
which may cause performance problems; before doing
anything measurements should confirm that these
are problems; but in any case I wanted to record
them before I forget all about it:

(1) Exceptions used for control flow. This is
considered bad;     exceptions should be used for
unexpected failures, not to     communicate
"return values". (See Effective Java for
justification; also, I seem to remember that we
found that part of NetBeans' long startup time had
to do with the JDK throwing thousands of
exceptions when computing the font path.)

To be specific; NameNotFound exception is used
whenever we look up setting values and it's not
defined. For ProxyContext, this means that a
single lookup causes a series of exceptions to be
thrown. (And when exceptions are thrown, the vm
has to record stack information etc which is costly.)

I don't know if we can do anything about this
since this is part of the Context API from JNDI,
but perhaps there's something we can do about
this; either document that a null return value
means name not found (which means you can't store
null as the value, which is probably acceptable
since in most project settings cases the treatment
of the two are identical), or perhaps we can think
of something even better.

(2) Right now we're adding more contexts into the
proxy context than is necessary; we're adding in
ALL the contexts (defaults, different
configuration types, etc.) because
TreeNodeContext.computeContexts() doesn't know
which specific name we're looking for. It could be
enhanced to lazily only compute the contexts
relevant to the specific name.

(3) In some cases we're adding in empty contexts
(Context.empty). You can end up with multiple of
these. I presume this was done for simplicity (the
delegates array has already been sized?). But in
any case it seems like having a 0-sized array
(when there are no delegates) or simply leaving
out Context.EMPTY would be better (fewer lookup
operations to be called).

(4) We've added (well, I haven't putback yet)
Defaults folders which can hold default values for
configuration types. This means that there are
additional contexts to be searched when doing
lookup. An alternative to this would be to -copy-
default values into a project when it's created
from the Defaults folders provided by the natures.
This will make lookup faster. It will however also
make the project files larger. It has the
"disadvantage" that if the defaults change in the
future, the project still uses the old ones - but
that can also be viewed as an advantage
(predictable builds).

(5) To compute contexts (computeContexts()) we use
the configuration manager, which returns
Configuration[] objects; these have their display
names etc. initialized. This is overkill for what
we need; which is simply to walk over the
configuration type folder and pick out active
contexts. It might be beneficial to add some
convenience methods to the ConfigurationManager
which provides Context objects for the active
configurations (and internally doesn't fully
initialize the configuration objects but uses its
internal knowledge of how the PFS is laid out to
compute the results.)

(6) The value notification of changes causes LOTS
of event objects to be created - this is because
it's using the standard JNDI notification scheme.
It might be possible to do something more efficient.


I think I had a few more ideas but they seem to
have vanished. I'll add them later if they come back.