Some observations:

opening of TC is not as fast as it should be - see for example issue #63590

first usages is likely affected by
- init of form itself. namely class loading. I noticed long time to load
FormUtils probably it loads a lot of Swing classes. 
- init of multiview
- init of property sheet (this was shown by default in 3.x and maybe in 4.0)

i will look further...

common for all usages:

- opening of components in winsys

- BeanInfo searching (yes, this is slow not only for the first form). we might
need to reevaluate Utilities.getBeanInfo and how our classloaders scales when
there are so many failing attempt to load classes. Generaly the less items on BI
search path the better as we try to load from all modules.

- ~10% of time is spent in FormEditor.loadFormDesigner calling
RM.repaintDirtyRegion immediately. I am not sure if we can optimize this. Maybe
there is too many things that are already marked as dirty. Generaly we do not
have big chance to offload processing from AWT and provide feedback continualy

- minor but perhaps easy to fix: extensible PersistenceManager is vaste of
resources, we have just one so the class can be simplified and we do not nee to
parse form file twice. Once from canLoadForm and then from load form
- minor: another sample of ineffective processing - FormUtils.canBeContainer() 
sort the array of forbidenContainers and use binary search

more related to first usage:

- init and validating of palette is slow. there are many items that have to be
loaded and most visible parts are XML parsing, icon loading

We are violating our UI responsiveness rules here a lot. P2 seems to be more
accurate.

I have performed a measurement of form opening using OptimizeIt Profiler 4.2
with JDK 1.5.0_05-b05 on Windows XP (Intel Centrino 1.7GHz, 1GB of RAM).

Test cases:
withoutComponents - empty JFrame container
sameComponents - form with 50 buttons
differentComponents - form with 36 distinct components from Swing category
nestedContainers - form with 20 nested JPanels

The times are in milliseconds and are measured in a "profiling mode"
e.g. the times are 3 to 6 times higher than the real times.

The first column shows time of the first opening, the second column shows
time of the second opening and the third column (if present) shows number
of loaded classes.

NB 4.1 (first/next/#of classes)

withoutComponents    5038  1682     473
sameComponents       6800  3185
differentComponents 15763  7681     960
nestedContainers     6039  3645


Dev20051117 (first/next/#of classes)

withoutComponents      5929  1943     508
withoutComponentsNL    6249  1803     550
sameComponents         7741  3875
sameComponentsNL       7201  4116
differentComponents   15442  7861    1060
differentComponentsNL 14861  8082
nestedContainers       5919  2975
nestedContainersNL     6950  2584

The opening in development builds of NB5.0 is about 4% slower (in average)
than in NB4.1.

Differences in loaded classes:

(4.1 versus 5.0)
- new classes of the form module
- palette

(5.0: old layout support versus the new one)
- swing-layout library
- support classes for free design

Detailed analysis of the first opening of withoutComponents
and differentComponents follows.

*** DifferentComponents ***

OpenAction.performAction()
.TopComponent.open() 92%
..FormDesigner.componentShowing() 82%
...FormEditor.loadFormDesigner() 67.7%
....GandalfPersistenceManager.loadForm() 64.8%
.....GandalfPersistenceManager.restoreComponent() 56.6%
......RADComponent.initInstance() 44.4%
.......bean's constructors 25.8%
.......bean info search 18.1%
......GandalfPersistenceManager.loadComponentProperties() 2.3%
.......initialization of property editors, XML parsing etc.
......LayoutSupportManager.prepareLayoutDelegate() 1%
.....determination of form's super class (JMI) 3.6%
.....FormModel.setFormBaseClass() 3%
......bean info search 2.1%
....PersitenceManager.getManagersList() 1.2%
.....classloading caused by GandalfPersistenceManager 0.6%
...FormDesigner.initialize() 11.5%
....RADComponent.createBeanInstance() 6.9%
.....bean's constructors 6.9%
....FormUtils.copyPropertiesToBean() 2.7%
.....cloning of property values 2.6%
...FormEditorSupport.checkFormGroupVisibility() 3.1%
....deserialization of form group 2.9%
..PaletteFactory.createPalette() 2%
..deserialization of ComponentInspector 0.8%
..deserialization of form settings 0.4%
..initialization of FormToolBar 0.4%
..PaletteSwitch.run() 3.7%
.CloneableEditorSupport.createCloneableTopComponent() 7.7%
..class loading (caused by FormUtils?) 5.9%
..initialization of multiview

Summary

32.7% bean's constructors
26.7% class loading and bean info search
3.7% window system
3.6% JMI
2.6% cloning of property values
2.0% palette
0.4% form settings

*** WithoutComponents ***

OpenAction.performAction()
.TopComponent.requestActive() 1.2%
.TopComponent.open() 93%
..FormDesigner.componentShowing() 66%
...FormDesigner.loadFormDesigner() 54%
....GandalfPersistenceManager.loadForm() 25.6%
.....determination of form's super class (JMI) 11.1%
.....FormModel.setFormBaseClass() 7.8%
......bean info search 5.8%
.....GandalfPersistenceManager.loadComponent() 5.4%
......LayoutSupportManager.prepareLayoutDelegate() 2.9%
....UIManager's defaults switch 1.4%
....class loading 20.4%
....PersitenceManager.getManagersList() 3.2%
.....class loading 1.8%
....JavaCodeGenerator.initialize() 1.6%
.....JavaEditor.findSimpleSection() 1.1%
...FormEditorSupport.checkFormGroupVisibility() 7.9%
....deserialization of form group 7.6%
...FormDesigner.initialize 4.2%
....class loading 1.9%
..FormDesigner.<init> 9.1%
...PaletteFactory.createPalette()  3.7%
...deserialization of ComponenInspector 1.8%
...initialization of FormToolBar 1.4%
...deserialization of form settings 1%
..PaletteSwitch.run() 12.4%
..TabbedContainer.<init> 1.8%
.CloneableEditorSupport.createCloneableTopComponent() 5.7%
..initialization of multiview

Summary
30% classloading and bean info search
16% palette
13% window system
11% JMI
1% java editor (findSimpleSection())
1% settings

I have changed the FormUtils class not to reference so many Swing classes.
It contains only names of the classes by now. See

/cvs/form/src/org/netbeans/modules/form/FormUtils.java,v
new revision: 1.107; previous revision: 1.106

This change doesn't seem to have a negative impact on the performance
of any of the mentioned test cases. On the other hand the first
opening of an empty form is 4% faster in average (on W2K).

the palette window now opens at the same time as the properties window when form
designer opens.

Checking in FormEditorSupport.java;
/cvs/form/src/org/netbeans/modules/form/FormEditorSupport.java,v  <-- 
FormEditorSupport.java
new revision: 1.192; previous revision: 1.191
done

Discussed with performance team -- we have done everything possible for the NB
5.0 timeframe and the issue is now partially addressed (no regression from the
previous release), making it a P3. 

We still want to investigate deeper in the future and, if possible, to introcude
more improvements.

Feedback from NB5.5.1 performance survey:

The form editor can take a long time to start when I have many custom components.

*** Issue 96622 has been marked as a duplicate of this issue. ***

Recent measurements:

Open Form file (20kB)	fail	One of the measuredTime(s) [ 8664 146 214 134 ] > expectedTime[1000] - performance issue
(it's ok if the first usage is in boundary <0,2*expectedTime>) .

Open Form file (20kB) if Editor opened	fail	One of the measuredTime(s) [ 2989 167 137 153 ] > expectedTime[1000] -
performance issue (it's ok if the first usage is in boundary <0,2*expectedTime>) .

According to NB Bug Priority Guidelines, UI responsiveness of a feature breaking UI guidelines ->P2

I think we agreed time ago this a P3.

There are several issues covering specific aspects of slow opening of form, see issues 179407, 180756, 169802. Hence, I am closing this non-specific issue.

*** This bug has been marked as a duplicate of bug 179407 ***