I've been doing some performance tuning of Creator lately, and looking
at performance hotspots on various user actions, such as project open.

I found a bottleneck in NetBeans that I think is accidental; it's
related to

ant/project/src/org/netbeans/spi/project/support/ant/EditableProperties.java

First, look at this:

    private boolean alphabetize = true; 

    ...

    /**
     * Creates empty instance which items will not be sorted by default.
     */
    public EditableProperties() {
        items = new ArrayList();
        itemIndex = new HashMap();
    }

NOTE: Even though the Javadoc for the null constructor says that the
list will NOT be sorted by default, the sorting flag (alphabetize) is
set to true. All lists are set to sort by default!

Take a look at this constructor (which I believe is the performance
culprit; I didn't have line numbers in my profiled output to
disambiguate the constructors but I do see that for most of the
calls to addItems it's coming from one of the constructors):

    /**
     * Creates new instance from an existing one.
     * @param ep an instance of EditableProperties
     */
    EditableProperties(EditableProperties ep) {
        this();
        Iterator it = ep.items.iterator();
        while (it.hasNext()) {
            Item item = (Item)it.next();
            addItem((Item)item.clone(), false);
        }
    }

Again, it will use sorting by default, and it's iteratively inserting
numbers from one list into another. If you look at addItem(), you'll
see that its sorted-insert operation is very slow - it's doing an
ArrayList search, followed by an ArrayList insert (which will on the
average cause half of the elements in the array to have to be moved).

Thus, the EditableProperties copy constructor has complexity O(n^2) !

At first I thought perhaps the behavior of sorting was accidental -
somebody left the flag on after some debugging. But I see in the CVS
checkin comment that this was done to improve VCS interaction
behaviors; presumably keeping the property lists sorted will minimize
the changes in updates in CVS.  (I'm not sure why since the hashcodes
for Strings seem stable too, but there probably are other reasons I'm
not thinking of. And in any case, an alphabetical order seems more
readable if not less diff-prone.)

So if the sorting behavior needs to be kept, there are still easy things
to do to improve the performance here.  If we except addItem() to be
called a lot (from outside of the class), then we should use a different
data storage than an ArrayList, such that it supports faster inserts.

However, if it's really only from copies (and in my scenario, that's 
what the stacktraces are telling me), then the copy constructors should
simply be rewritten.

For example, if ep (the EditableProperties object being copied) also has
the alphabetize flag set, then the properties are already sorted, so we
can simply iterate over its items ArrayList, clone each object and 
append it to our ArrayList. No need to call addItem() to do this. 
If on the other hand the EditableProperties object to be copied doesn't
have alphabetize=true, then we should copy out all its items, put them
in our ArrayList and then sort the whole array list using Collections.sort.

(And obviously, the javadoc for the constructors need to reflect what
the sorting-default is.)

(Observed in 4.1 but I see the code in 5.0 is identical.)