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

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

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

True. However this is done entirely by JavaHelp, not NetBeans.

Waiting for an owner; not part of NetBeans.

Tim now maintains this part. I don't expect he will fix this issue,
just push and convince others outside netbeans to do something.

Whom should I push?

JavaHelp makers IMO. Don't know exact person, sorry.

I doubt the JavaHelp side is going to improve much here (certainly not
to less than one second), since a lot of data gets merged when help is
first opened. 

Could we improve things by doing the merge only once, perhaps the
first time Help is opened in the IDE, and keeping the merged help in a
file somewhere? The help system could do some sort of check the first
time the help is opened in a given session to make sure that the
installed help sets have not been changed.

One possible problem: someone manually replaces a help set jar in the
build. However, I think this is a corner case which we don't need to
optimize for. And perhaps the thing that checks the installed help
sets would be able to check the jar manifest for version number?

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

I'm not sure how or if you can premerge help sets - the JavaHelp API
permits you to merge them at runtime, but that is different from
merging them into a new static XML. I think you would need to
essentially duplicate all the logic currently in the navigators for
merging items, which would be onerous and a source of bugs (would get
out of synch with the code in JavaHelp itself).

Maybe JavaHelp just needs to be optimized better for merging (i.e.
independently of NetBeans). Ten seconds certainly doesn't sound like a
reasonable amount of time for a modern processor to spend doing
something as straightforward as collecting a bunch of IDs and
collating them.

bumping to P3, but at the same time will pursue improvement on the JH
side.

 FYI, today's numbers :

[nb_dev](200407141800), [jdk1.5.0](beta3 - b58) on
our lab machines:
---------------------
 1st usage 	4577 	4780 	8105 	5628 	5902
 2nd usage 	264 	437 	199 	118 	155
---------------------

Test case:
- run IDE
- Push menu Help | Help Contents
EXPECTED RESULT: Help Window is opened within 1000ms
--------------

on my faster notebook / RH Linux
9/Gnome/JDK1.5.0(beta3), it takes :
~3800 ms

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

IMO, file a JavaHelp bug and close this issue - not much we can do on our side, and in 
fact, opening help is *responsive* - the merging help sets dialog comes up with quickly.  

Compared to the things refactoring does, this just doesn't seem that bad.  Even not 
considering that, this is not a P2 - nobody's going to go use a different IDE because 
merging help sets takes too long.

Well, for starters we need thread dumps or profiler results showing
precisely *what* is so slow when opening help, so we can know whether
the slow code is ours or JavaHelp's, and which part is slow. Otherwise
anything written in this report is just speculation.

I have profiler output from OptimizeIt. Shall I attach it here? 

Summary: Work is done in AWT thread. Most of time (over 90%) is spent
in JavaHelp.showHelp() (NB code). (Next is already in JavaHelp code.)
Over 85% is spent in JHelp constructor. Most of time about 70% takes
call of JHelp.setupNavigators (includes merging; IndexView 35%,
SearchView 17%, TOCView 15%) and JHelp.updateUI() 15%.

Created attachment 16442 [details]
Snapshot fro OptimizeIt

Output from OptimizeIt is provided. What to do with this issue?

Well, if the bulk of the time is clearly in JavaHelp code, then we
need to file a performance bug for JavaHelp itself, mention the bug #
here, and close this.

Issue is filled to Bugtraq against JavaHelp as #5107351.

currently marked as dup of #5107221

verified in NB4.1(200501241900)