What makes you think this is a regression? Nothing about universe scanning has changed very recently.
EditorBookmarksModule.restored is asking to load open projects, which forces apisupport to do some computation to
register its classpaths. AFAIK it has been this way for a long time.

It is regression against last NB release (against NB 5.5)

Did editor behave differently in NB 5.5 than in NB 6? I don't see anything in apisupport's behavior that would be any
different. When someone asks to load and then open a NB project, as editor is doing here, apisupport must register its
classpaths in GPR, and this has always required finding a list of universe modules so it can determine the correct
classpath.

Well, I'm not sure if this bug is regression or not. But I don't remember, that NB 5.5 startup took that long.

jbecicka: do you mean big IDE 6.0? Than slower startup is natural...
Editor bookmark guys, can you comment? Is it possible to do things differently in EditorBookmarksModule.restored ?

While I agree this is a problem, for P2 we should prove exactly where the code is worse IMO.

No I don't. I mean Basic IDE, which has less modules than NB 5.5 and long startup is not natural.

God save the IDE, where bug reporter is required to prove where exactly in code is the bug.

Startup of NB takes several minutes, without any UI indication. It is P3. OK. Great.

I'm not aware of any change regarding bookmarks loading since 5.5. Is it really the culprit? I've looked into the
bookmarks module and we could possibly make the loading more lazy in case there is no opened editor yet. Would it help
to resolve this issue?

IMO editor/bookmarks could use ProjectOpenedHook to intercept the project close operation, which it needs for saving
bookmarks in the project's files. It would be more efficient than asking for the list of opened projects and listening
on its changes and computing what projects had been closed. Feel free to reassign.

You can only implement ProjectOpenedHook in the project itself. Foreign code has no access to it.

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

There's one path that we should explore, in future, regardless of resolution of this issue, and that is, split the
"universe". Most of the NetBeans developers are wasting their time updating the whole CVS and building the big IDE.

I believe we should come up with a reasonable granularity and a process (guideline) on how to work on your module while
keeping your development platform up-to-date enough. We'll be facing the granularity issue anyway if we decide to move
onto  a different version control system for NB sources.

I don't understand, why this issue is P3, and not P2.
Definition of P2 according to bug priority guidelines:
# UI responsiveness of a feature breaking UI guidelines (100ms, 1s)
# Significant scalability problem
# AWT thread blocked by a task which could run on background
# No or inappropriate indication of progress of a running task 

This issue meets all 4 criteria.

Only affects nb.org modules, i.e. only a handful of nb.org module developers, not general IDE users, so not a priority
relative to bugs affecting anyone.

VCS granularity != build granularity != IDE performance. If we move to e.g. Hg we would likely want a single repo for
all (stable) sources; Hg is much faster anyway. Build granularity could be changed independently of VCS, but would
require a substantial rewrite of our build system - certainly not an option for the short term. IDE performance of
project loading depends on the algorithm used to compute certain important things like the classpath; this is
independent of the VCS and only loosely related to build granularity. Project loading optimizations generally fall into
simple optimizations (delay unnecessary work, speed up basic operations) or cache creation and maintenance (with
accompanying risk of not detecting stale cache conditions). A recent build optimization based on a cache made a big
difference, though it introduced at least two regressions I know of (both now fixed).

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

I don't think it's possible to avoid loading the module universe, but I did put in an optimization which uses the scan
cache created by a build if there is one and it is up to date (see issue #105324). When that cache is usable, the result
is dramatically faster than a usual universe scan. Otherwise the IDE should quietly fall back to a full scan.

Checking in nbbuild/antsrc/org/netbeans/nbbuild/ModuleListParser.java;
/shared/data/ccvs/repository/nbbuild/antsrc/org/netbeans/nbbuild/ModuleListParser.java,v  <--  ModuleListParser.java
new revision: 1.47; previous revision: 1.46
done
RCS file:
/shared/data/ccvs/repository/apisupport/project/src/org/netbeans/modules/apisupport/project/universe/NetBeansOrgCachedEntry.java,v
done
Checking in apisupport/project/src/org/netbeans/modules/apisupport/project/universe/NetBeansOrgCachedEntry.java;
/shared/data/ccvs/repository/apisupport/project/src/org/netbeans/modules/apisupport/project/universe/NetBeansOrgCachedEntry.java,v
 <--  NetBeansOrgCachedEntry.java
initial revision: 1.1
done
Checking in apisupport/project/src/org/netbeans/modules/apisupport/project/universe/ModuleList.java;
/shared/data/ccvs/repository/apisupport/project/src/org/netbeans/modules/apisupport/project/universe/ModuleList.java,v 
<--  ModuleList.java
new revision: 1.35; previous revision: 1.34
done