This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 196353 - 5s - too much MakeLogicalViewProvider.LoadingNodes threads
Summary: 5s - too much MakeLogicalViewProvider.LoadingNodes threads
Status: RESOLVED WONTFIX
Alias: None
Product: web
Classification: Unclassified
Component: HTML Editor (show other bugs)
Version: 7.0
Hardware: All All
: P3 normal (vote)
Assignee: Marek Fukala
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2011-03-05 17:25 UTC by pepijn
Modified: 2012-11-20 17:14 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 177303


Attachments
nps snapshot (32.36 KB, application/nps)
2011-03-05 17:25 UTC, pepijn
Details
nps snapshot (2.89 MB, application/nps)
2012-01-30 12:20 UTC, Egor Ushakov
Details
nps snapshot (159.78 KB, application/nps)
2012-01-30 12:22 UTC, Egor Ushakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description pepijn 2011-03-05 17:25:14 UTC
This bug was originally marked as duplicate of bug 169054, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 7.0 Beta 2 (Build 201102140001)
VM: Java HotSpot(TM) Client VM, 21.0-b03, Java(TM) SE Runtime Environment, 1.7.0-ea-b132
OS: Linux

User Comments:
pepijn: Saving project metadata for a large C/C++ project



Maximum slowness yet reported was 5193 ms, average is 5193
Comment 1 pepijn 2011-03-05 17:25:20 UTC
Created attachment 106750 [details]
nps snapshot
Comment 2 Jaroslav Tulach 2011-03-06 06:48:25 UTC
I am not sure if that is the cause of slowness, but there seems to be way too much MakeLogicalViewProvider.LoadingNodes threads. One would be enough I guess.
Comment 3 Egor Ushakov 2012-01-30 12:20:14 UTC
Created attachment 115383 [details]
nps snapshot
Comment 4 Egor Ushakov 2012-01-30 12:22:24 UTC
Created attachment 115384 [details]
nps snapshot
Comment 5 Jaroslav Tulach 2012-04-10 02:02:12 UTC
UI was blocked for 12s this time, that is at least P3.
Comment 6 turneliusz 2012-06-11 08:00:29 UTC
For me blocked for 7 seconds
Comment 7 Leonid Lenyashin 2012-10-30 21:09:45 UTC
There was no activity on this issue for quite a long time. We apologize that the issue was not addressed so far due to lack of development resources. We might not have time in near future to fix this problem, so it is closed as WONTFIX.
If the issue is still critical for you please do not hesitate to REOPEN it.
Thank you for using our product and reporting bugs. We are really sorry that we were not able to fix this issue timely.

Regards,
CND team.
Comment 8 Leonid Lenyashin 2012-10-30 21:11:47 UTC
Sorry, this one should probably stay open.
Comment 9 Alexander Simon 2012-10-31 06:46:43 UTC
There are no new reports against 7.3.
Last reports are about csl.
Reassign to evaluation.
Comment 10 Milutin Kristofic 2012-11-06 17:23:53 UTC
org.netbeans.modules.html.validation.ValidationTransaction.initialize()	34.436096	2,779 ms (34.4%)	2,779 ms
Comment 11 Marek Fukala 2012-11-20 14:33:27 UTC
(In reply to comment #10)
> org.netbeans.modules.html.validation.ValidationTransaction.initialize()   
> 34.436096    2,779 ms (34.4%)    2,779 ms

?? What does that mean ??  Where is it called? What exception report? BTW this is valid time for this as it does lots of first-time initializations.
Comment 12 Milutin Kristofic 2012-11-20 15:10:28 UTC
As Simon wrote, in last snapshot there is csl issue. The snapshot is http://statistics.netbeans.org/exceptions/exception.do?id=598280 . If you look at editor parsing loop thread, you can see GSFHintsProvider asking for html validation - that's the call I wrote here.

Marek, just open snapshot, find (ctrl+f) for org.netbeans.modules.html.validation.ValidationTransaction, if is valid for initialization just close this report.

Thank you.
Comment 13 Marek Fukala 2012-11-20 17:14:22 UTC
I saw the call in the latest snapshot already but was just surprised why this was assigned as a bug to me since the call was in a proper thread. I thought that some of the other snapshots shows its called in EDT or in other incorrect place.