Hm, isn't Find dialog part of search module or find module? I'm just
asking, I don't know exactly.

Yes, it is created each time the Find action is invoked.

I think this should be re-investigated for 4.0.

Let's re-investigate:

even on my laptop with 2GHz processor+1GB RAM first open takes
regularly  sligtly more than 1sec. Next attempts are usualy within
500-600ms. We should profile what is happening during first call and
make it faster. Caching is probably not a way how to solve this.
Perhaps we should init tabbed panes in more lazy manner. Just guessing.

It seems I have much faster computer - it appears almost immediatelly,
even after computer restart.

Nevertheless, I found a probable bottleneck - its the initialization
of the panels, indeed. Particularly initialization of the Object Type
panel is slow. I will find some ways of how to improve it.

Created attachment 17863 [details]
suggested patch

The attached patch changes the Search dialog's behaviour such that the
panels for individual tabs are not fully initialized until they are
made visible. Specifically for the Object Type panel, this means that
loading of the list of object types is delayed until the panel is
selected. This should significantly reduce initialization time of the
dialog.

I will integrate the change on Monday, whether it fully solves the
problem or not, because I consider it to be an improvement... unless
somebody objects against the integration.

I would appreciate if somebody measured how much does this change help
(can be even before the integration).

I applied the patch to the CVS trunk.

Modified files:

    utilities/src/org/netbeans/modules/search/:
        SearchTypePanel.java   (1.19)
        SearchPanel.java   (1.24)

Latest results from automated UI responsiveness tests show slightly
improved time on WinXP, Linux results are missing due to some problems
with test suite.

This helped a little bit but it was not the major problem.

I looked at what could cause such a slowdown and I think I know what
the problem - there are too many .class files generated from the
source code. So I will do the following changes and I hope it helps to
reduce the time significantly:

  - eliminate *BeanInfo classes for default search types
  - reduce nested/inner classes

Currently, there are 34 .class files generated from 16 source files. I
plan to eliminate 4 source files and additional 6-10 inner classes so
the number of .class files could drop to 20-24.

I integrated another improvement. It by-passes BeanInfo objects for
SearchTypes defined in the Utilities module and also reduces number of
nested/inner classes in SearchPanel and SearchTypePanel.

Modified files:

utilities/src/org/netbeans/modules/search/:
   SearchPanel.java   (1.25)
   SearchTypePanel.form   (1.3)
   SearchTypePanel.java   (1.20)
   types/FullTextType.java   (1.41)
   types/FullTextTypeBeanInfo.java   (deleted, last rev. 1.19)
   types/ModificationDateType.java   (1.28)
   types/ModificationDateTypeBeanInfo.java   (deleted, last rev. 1.18)
   types/ObjectNameType.java   (1.18)
   types/ObjectNameTypeBeanInfo.java   (deleted, last rev. 1.16)
   types/ObjectTypeType.java   (1.20)
   types/ObjectTypeTypeBeanInfo.java   (deleted, last rev. 1.13)

Another partial fix integrated - it reduces number of nested/inner
classes in ModificationDateCustomizer.

Modified files:

utilities/src/org/netbeans/modules/search/:
   types/ModificationDateCustomizer.form   (1.18)
   types/ModificationDateCustomizer.java   (1.30)

Another partial fix integrated - it reduces number of nested/inner
classes in TextCustomizer.

Modified files:

utilities/src/org/netbeans/modules/search/:
   types/TextCustomizer.form   (1.15)
   types/TextCustomizer.java   (1.25)

The changes made and integrated yesterday significantly improved
initialization time and the time is below limit on all tested
platforms. The change made today can only improve the time.

Marking as FIXED.

verified