Is there a measurement for NetBeans 4.1 to find out how it has changed?

Yes, I found results we have measured for NB41 (build 200505031930).

  Project node popup in Projects View
   [ ms ] / 100 ms 	FC3 	JDS3 	Sol9 	Sol10 	W2K 	WinXP
 	1st usage 	94 	N/A 	196 	132 	78 	88

It's caused by Petr's commit:
User: pkuzel  
Date: 05/05/05 06:42:24

Modified:
 /java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/
  J2SEPhysicalViewProvider.java

Log:
 #57874 contract honored - Actions on project node.

File Changes:

Directory: /java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/

The change is rather trivial:

                FileObject fo =
Repository.getDefault().getDefaultFileSystem().findResource("Projects/Actions");
// NOI18N
                if (fo != null) {
                    DataObject dobj = DataObject.find(fo);
                    FolderLookup actionRegistry = new
FolderLookup((DataFolder)dobj);
                    Lookup.Template query = new Lookup.Template(Object.class);
                    Lookup lookup = actionRegistry.getLookup();
                    Iterator it = lookup.lookup(query).allInstances().iterator();
                    if (it.hasNext()) {
                        actions.add(null);
                    }
                    while (it.hasNext()) {
                        Object next = it.next();
                        if (next instanceof Action) {
                            actions.add(next);
                        } else if (next instanceof JSeparator) {
                            actions.add(null);
                        }
                    }
                }

and follows DataLoader mime based action pool pattern.

Could you profile this (anti)pattern?

BTW it scattered all around code base in all project types.

XML fs merging on first read is quite slow....

> XML fs merging on first read is quite slow....

Have you seen this in profiler? The merge is done during first start and later
BinaryFS that is already merged is used (assuming the cache is from previous rn
is valid).

There is no need to do the full actionRegistry pattern in the popup invocation.
You can initialize your actionRegistry at project opening which takes long
anyway and is(will be) covered with progress indication.

Interesting idea. Reminding that the same pattern is used in all project types. 

Reassigning to javacvs since it is a javacvs code even it is hosted under the
java/j2seproject.

Returning... No, it's generic project contract that all project type impls must
follow. Profiler also injects some actions AFAIK.

Droping priority: user impact is very limited (on contemporary hardware).

> Droping priority: user impact is very limited (on contemporary hardware).

P3 enhancement? Good joke. :-)))

However, your HW configuration is irrelevant. Officially recommended supported
configuration is what matters (see Release Notes). And UI limits (100ms in this
case).

It is javacvs code even it is commited into every project type, this is even
worse, it slowed down all project types. The javacvs module is the only one who
can solve it, eg. by preinitialization of the CVS menu in the warm up task.
Otherwise each project type will need to schedule the same warm up task doing
the same preinitialization of the CVS menu, which will be slow.

Three players here: project type impls, CVS module and infrastructure.

Sorry Tomas for not accepting, but as Tonda suggested it could be sampled during
opening project. Warm up tasks are evil and should be avoided if here exists
progress covered hook triggered by related user action. It must be done in all
project type implementations, piece by piece. Therefore I do not think it's wise
to blame project type impls :-).

At CVS side I have implemented asynchronous sub-menu construction - loading CVS
SystemActions in RP:

Checking in ProjectCvsMenuItem.java;
/shared/data/ccvs/repository/javacvs/cvsmodule/src/org/netbeans/modules/versioning/system/cvss/ui/actions/ProjectCvsMenuItem.java,v
 <--  ProjectCvsMenuItem.java
new revision: 1.10; previous revision: 1.9
done

Remaining player is infrastructure - its scalability. It's pity that SFS and
Lookup infrastructure seems to be slow to hit 100ms constraint. The registration
format follows standard suggested pattern (copied from DataLoader MIME based
action extensions).

Tonda, could you push on speeding up the infrastructure, please? Note there is
registered only one instance (2 with optional profiler) and suggested code
template uses FolderLookup that narrows searched context to exact SFS folder. 

I hope it's last time I see this issue assigned to javacvs component.

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

The measured times are now slightly over the expected numbers (200ms for 1st,
100ms for next):

   JSE Project node popup in Projects View
   [ ms ] / 100 ms	FC3	Sol9	Sol10	W2K	WinXP
 	1st usage 	220 	281 	258 	145 	182
 Subsequent usage 	130 	145 	136 	89 	84

verified