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.
I'm not sure what has happened but the new 6.0 final version has the worst performance that I've used thus far and is VERY frustrating to use(I have used both beta 6.0 versions and both 6.0 release candidates). Currently, if I am switching between jsp pages (that I have opened in the editor) my machine basically becomes unusable (freezes) for almost a minute...sometimes longer. Also, if I make a change and save it...my machine again becomes usable for another minute or longer while I wait for NB to save it.
Also, it is very slow closing a jsp file. It is also slow switching from a java page to a jsp.
Can you please attach a few threaddumps taken during the high CPU load?
Created attachment 53874 [details] Thread Dump 1 - Opening jsp
Created attachment 53875 [details] Thread Dump 4 - Closing a jsp
Created attachment 53876 [details] Thread Dump 2 - Saving jsp
Created attachment 53877 [details] Thread Dump 3 - Saving jsp
Created attachment 53879 [details] ThreadDump 5 - Added a couple of jar files to my classpath
Thanks for the threaddumps, but non of them is complete. Can you please remake them and attach the complete content? Is it also possible to make them without the annoying line wraps? Thanks. As for the particullar dumps: #1 - opening JSP - in the visible part there doesn't seem to be anything special. Can you please confirm that the opening time is slow for all JSP files. Or that project specific? Is there really a positiove difference in the opening time between RCx and FCS? BTW Was the CPU loaded at all? Or just the UI was frozen? BTW, how long the opening take? #2 - closing jsp - There is nothing going on in the "closing JSP" TD. Was the CPU loaded? How long the closing takes until the file is closed? #3 - saving jsp - there might be some parser problems, it is strange, I have never heard any complains about saving, again the TD is not complete, please make it again. Can you please specify your jdk, platform, CPU, memory etc? Also please provide some more precise description of what is happening during the "slowenes" - whether CPU is loaded, or just UI frozen, how long the actions takes etc. BTW, do you use local filesystem or remote one for your project? Can you reproduce after cleaning the userdir and creating a new project? Thanks for providing the data.
> > BTW, do you use local filesystem or remote one for your project? Can you reproduce after cleaning the > userdir and creating a new project? > I would like to try this. How do I clean the 'userdir' for this project?
> > Thanks for the threaddumps, but non of them is complete. Can you please remake them and attach the complete content? > Is it also possible to make them without the annoying line wraps? Thanks. > What is the recommended way of capturing these thread dumps?
a)Your userdir is located in {your disk}:/Documents and Settings/{your username}/.netbeans/6.0 Deleting the whole folder (or /var folder in it, what keeps your configuration settings intact and has the same result) you force NetBeans to recreate data cache and thus prevent problems with somehow corrupted cache (which is sometimes also source of problem). b)After pressing Ctrl-Break in command shell window, use Ctrl-A for "Select all" and paste to notepad to prevent insert of unwanted chars (what could happen in Wordpad/MS Word and similar text editors). This shoulds retain original raw text structure.
Created attachment 54146 [details] Opening first JSP thread dump
Hi, I just attached a new threaddump which was created while opening the first jsp page after the NB has just been started. By the way, I recreated my project and everything now seems to be working fine. However, I have noticed that the first JSP page that I open after I have started NB (each day) nearly kills my machine for a minute or two. Once loaded, everything is ok...at least for awhile. I also have noticed that if I'm not doing any jsp editing for awhile (maybe an hour or so) and then I open a JSP the same thing happens to my machine (it becomes usable) and I have to wait a minute or 2 before I can use it.
It looks like the problem is jsp parser performance - how many libraries, jars, dependent projects and tlds do you have in the project?
I can reproduce similar thread dump while opening logger/uihandlerserver module from NetBeans CVS and trying to open uploaddone.jsp file. This scenario doesn't block IDE totaly, but it run CPU on 100% for few seconds.
Created attachment 54158 [details] 3 thread dumps - few seconds after opening file, after few seconds and at the moment of finished CPU activity
> > It looks like the problem is jsp parser performance - how many libraries, jars, dependent > projects and tlds do you have in the project? > libraries - 1 (struts) jars - 236 dependent projects - 0 tlds - 6
Can I ask what are all these jars for? It looks like this is the reason - jsp parser parses all the jars on the classpath so if you have so many of them it may take some time.
Created attachment 54680 [details] this stacktrace is catched during jsp file editation - cpu starts running for 100% for few seconds after cc invocation
We have lots of very large jars and a large loose codebase directory in our web classpaths -- and these are quite necessary. I'd expect the parsing results to be cached... [Note I'm not in any way associated with the original reporter, but will be throwing in my vote for this issue. Though the NB 6 JSP editor is very nice overall, its performance is truly atrocious at the moment.]
*** Issue 122973 has been marked as a duplicate of this issue. ***
There are plenty of problems in this issue reported, the attached threaddumps shows different activities. This needs to be investigated more thoroughly, not time for this now.
*** Issue 123666 has been marked as a duplicate of this issue. ***
I face similar issues when editing a .jsp file: If there is one or more taglib jsp directive in the page, and you open a tag by typing a '<' or press Ctrl-Space inside a non-jsp standard tag, the auto-completion box initiates('Please wait...' message is shown) and consumes a lot of CPU for a few seconds(10 to 30 as I noticed) until finaly the pop-up menu become available. When I initiate auto-completion inside a standard jsp tag or if there are no taglib directives, auto-completion responds immediately. All of the above apply for my Windows XP box. I have NetBeans installed on a Linux laptop (Ubuntu 7.04) with exactly the same configuration for NetBeans ,working with the same project through svn and there no delays in auto-completion. I will paste the contents of the test jsp file below(it's the auto-generated forwardToJSF.jsp, slightly modified): ------------------------------------------------- <%@page pageEncoding="UTF-8"%> <%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%-- This file forwards to the entry of JavaServer Faces application. See <welcome-file-list> in web.xml file. --%> < <jsp:forward page="index.jsp"/> -------------------------------------------------- I will attach the Thread Dumps I've taken, one with NetBeans idle, and one with auto-competion on the go. And just in case it's needed, I will also attach the NetBeans log.
Created attachment 55441 [details] NetBeans Idle Thread Dump
Created attachment 55442 [details] auto-completion in progress Thread Dump
Created attachment 55443 [details] IDE Log File
Thanks for the detailed report. From what you wrote, some other reports and the attached threaddump it looks like a problem with jsp parser, more specifically with the TldLocationsCache. It looks like there is a lot of tld files to parse. "Init TldLocationCache" daemon prio=2 tid=0x2add2400 nid=0x770 runnable [0x2f6be000..0x2f6bfc94] java.lang.Thread.State: RUNNABLE at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:133) [snip] btw, fragou, is the completion also that slow if you invoke it again, without modification of the document, and also if you modify the document. To make it more clear: 1) open the jsp file 2) invoke the cc => I guess now you wait for the 10-30 seconds. 3) close the cc (press ESC) 4) invoke again => is the time the same or is it faster? 5) close the cc again 6) modify the document 7) invoke the cc again => what is the cc time now? Thanks for clarifying also this. Regards, marek
can someone from QE try to reproduce the problem on win XP? Please refer to markjl9's report for the approximate project size. Thanks in advance.
Ok, mfukala, following the steps you sugested here are the results: First invocation of cc: ~10 secs. Second invocation: ~10 secs again. Invocation after editing: same results.. I performed a few more tests: 1) Removed the JSF taglib directives, leaving only the JSTL taglib. The file I'm editing is the one I included in my first message -'forwardToJSF.jsp'. This time cc is faster, 4 seconds. 2) I'm using a lot of jar files in the web project, and as you said 'there are a lot of tld files to parse'. So I removed everything exept the JSTL library. CC performance is dramaticaly improved - it takes hardly 2 seconds to popup. 3) After that, I added again the largest library I'm using, witch is Hibrenate. It contains all the jars from Hibernate Core 3.2 and Hibernate Entity Manager 3.3.1GA. This time code completion takes around 7 seconds to popup. Also I have to retract the statement that there are no delays of cc on my Linux machine.. I had some 'missing reference' problems that I didn't fixed because I was only editing jsp files on that machine... Once I included all libraries cc stoped being fast -it takes ~7 secs to popup. For anyone trying to reproduce the problem, I suggest the following steps: 1) Create a new Web project. 2) Select the Visual Web JavaServer Faces Framework (use *.jsf URL mapping or else 'forwardToJSF.jsp' will not be generated) 3) Add JSTL 1.1 Library. 4) Add JSF 1.2 Library. 5) Open forwardToJSF.jsp file and paste the following lines under the <%@page directive: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %> <%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %> <%@ taglib prefix="w" uri="http://www.sun.com/webui/webuijsf" %> 6) Invoke cc by typing a '<' character in a blank line. On my machine it took 14 seconds for cc to popup.
Tomas Mysik is currently looking at JSP parser performance problems, adding him to cc.
According to the latest comment I guess the problem can be with The TldLocationCache reparsing all jar files on the classpath each time it is asked for them. May have something to do with Files' timestamps on windows. Reassigning to Tomas Myslisk since he is supposed to work on the parser performance.
I'm looking at it.
Created attachment 55648 [details] Profiler snapshot (open+paste+cc)
I'm not able to reproduce that the second cc takes the same time as the first one. Maybe Windows specific, I'm on Linux. Can someone verify this please? Thanks. I will investigate more.
Adding David to CC because he can check this on Windows. Thanks David.
I tested latest fragou's suggested steps and CC is visible immediately (<1sec). Product Version = NetBeans IDE 6.0 (Build 200711261600) Operating System = Windows Vista version 6.0 running on x86 Java; VM; Vendor = 1.6.0_05-ea; Java HotSpot(TM) Client VM 1.6.0_05-ea-b04; Sun Microsystems Inc.
to fragou: could you please attach threaddump taken during the *second* cc? it would be very helpful, thanks
Created attachment 55756 [details] Thread Dump During 2nd CC
Tomas, please also note that I couldn't reproduce the problem on Linux yesterday, the second CC is up immediately. This is very strange because as I said last time it was performing the same as on Windows.. Is it possible this problem to be related with the JRE used by NetBeans? If so, how can I change this without re-installing?
Just an idea - cannot it be caused by modification time of the jars in the future? If the timestamps algorith was implemented incorrectly...
re. "change JRE used by NetBeans" - edit netbeans_jdkhome property in netbeans\etc\netbeans.conf
to fragou: Could you please send me the directory structure of your project (I mean listing of files in your project)? You can do this using e.g. "cd <project_dir> && find > listing" (on Linux). I have suspicion where could be the problem... Thanks.
Tomas, I switched to JDK 1.5 and there is no change in performance... I will send the folder tree of the test project I've suggested in a previous message because it's smaller than the regular project I'm working on, so it will be more clear for you to check what you want.
Created attachment 55886 [details] Test Project Tree
Fragou, I'm going to prepare module for you with extended logging - I hope it will be ready on monday. Could you please attach your testing project? I could ask QE for trying to reproduce. Thanks.
Ok Tomas, I'm attaching the test project and wait for the module you said.
Created attachment 55907 [details] Test Web Project
Hi fragou, sorry for the delay - I'm going to attach module with improved logging. Instructions: - download development version of NB from http://bits.netbeans.org/download/trunk/nightly/latest/ - replace 'netbeans/enterprise5/modules/ext/jsp-parser-ext.jar' with the attached one - start NB from command line using './netbeans -J-Dorg.netbeans.level=1000 -J-Dorg.netbeans.modules.web.jspparser_ext.WebAppParseSupport.level=500', ideally with clean userdir ('--userdir /tmp/cleannbuserdir') - reproduce the delay during the second code completion - attach messages.log file located in 'userdir/var/log/messages' Thank you for helping us, Tomas
Created attachment 56224 [details] module with improved logging
Hello again Tomas, I followed you instructions and reproduced the problem. I invoked the CC a few times, saved the file and invoked again and there is no deference in performance. I hope the log file I'm attaching will help you to investigate further. Regards, Chris(fragou)
Created attachment 56344 [details] Extended Log File
Hi Chris, would it be possible to test that scenario once more please? I'll attach new version of the module (caching logic was completely rewritten but it's not tested enough yet). Thanks, Tomas.
Created attachment 56515 [details] new version of module
Chris, I forgot: The problem I found in your messages.log was that the cache was not correctly created/verified. And so the code completion took so long for every time. It would be great if you were able to attach your messages.log file again after the testing of the new module version. Thanks.
Hi Tomas, I repeated the testing procedure with the new module and CC works like a charm! I also tested the normal project I'm working on and CC worked just fine. For the test project there was no delays at all, and for the normal one -that includes a lot of libraries, CC was slow only the first time invoked. I will attach the messages.log file after this message. One question: can I use this module with NetBeans 6.0? It would improve my daily work a lot. Thank you, Chris
Created attachment 56546 [details] Log File for Second Module
I too would *really* like to see this as a regular Update Center update for NB 6.0.
Hi Chris, first of all - thank you :) but it's still work in progress. The module has to be heavily tested, from the log you attached I see that you only invoked cc and that's definitely not enough. Other areas which have to be tested are: - functionality in Web project with custom build.xml - changing class path (adding library, removing library) - adding/changing/removing custom tld, tag files - editing web.xml (changing tag library mappings) - behaviour of the JSP editor in general - no regressions cannot be found As you can see, it's a lot of work. It would be very helpful if you could help us :) To your question about NB 6.0: hard to say because of areas mentioned above. Anyway you can try it - find that module in your NB directory, backup it and try to use the new one. Hope this help (and let us know :). Thanks, Tomas
Hello Tomas, Yesterday I replaced the module in NetBeans 6.0 with the new one and as far as I see, everything works normally. I've opened my normal project and CC was performing very nice -I even noticed an improvement in page validation(or maybe this is my idea). Today I reopened the project and got the same results. I think the cache is working right because when I invoked CC the list appeared immediately, it didn't scan the classpath again. Then I added a library to the project and after this I noticed a peak in CPU activity for a few seconds. Invoked the CC and it was 1-3 seconds slower the first time with no delays in subsequent invocations. After removing the library same thing happened. Next thing I checked was to create a JSP file with XML syntax. When I tried to add the tag libraries to the <jsp:root> element using the xmlns:x attribute, there was no CC with the list of available taglibs. When I do the same at a standard JSP file using the <%@ tablib prefix="..." uri="..." %> directive, invoking CC inside the quotes of the uri attribute brinks up a list with the aforementioned taglibs. This is not a performance issue but I thought it is good to report. Anyway, as far as I seen CC performance of the new module is good with XML JSP files. These are the tests I've made until now. Be sure that I will inform you if I find anything else. And I'm willing to help in anyway I can. Feel free to give me instructions for anything you thing that will be helpfull. I can't promise anything about response times though, because I'm quite a bit stressed lately. Thanks a lot, Chris
Hi Chris, thanks a lot for your report. Actually I just pushed all the changes into trunk because I have similar feedback from our QE. So please if you find any bug, feel free to file an issue. Thanks. This issue should be fixed by complete rewrite of caching strategy of tag libraries (changesets 62be113940b4, 4367d68ca4ab and 0f9daacfcaf3).
verified
Changesets for NB 6.0 backport: 4367d68ca4ab 62be113940b4 388a9220c4ca 0f9daacfcaf3
There's some deadlock in JSP parser - I have to look at it, please see issue #127672. Honzo, what about its impact on NB 6.0 backport? Thanks.
Temporarily removing 'release601_fixes_candidate2' keyword because of deadlock in issue #127672. I will try to solve it tomorrow.
Returning the keyword.
Just FYI, issue #127672 should be fixed now.
revision 1.14.8.1 date: 2008/03/07 17:55:36; author: rbalada; state: Exp; lines: +354 -518 IZ 123370 JSP editor VERY slow. Integration contains also fix for issue issue 127762 Following changesets have been backported to release601_fixes branch in file web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/WebAppParseSupport.java http://hg.netbeans.org/main?cmd=changeset;node=62be113940b4 http://hg.netbeans.org/main?cmd=changeset;node=388a9220c4ca http://hg.netbeans.org/main?cmd=changeset;node=0f9daacfcaf3 http://hg.netbeans.org/main?cmd=changeset;node=7524db6aed85 http://hg.netbeans.org/main?cmd=changeset;node=4cffe70b2b73 http://hg.netbeans.org/main?cmd=changeset;node=4367d68ca4ab http://hg.netbeans.org/main?cmd=changeset;node=0869473fbef6 http://hg.netbeans.org/main?cmd=changeset;node=5eb783048f20 This integration does not touch tests nor other files.
Correction of my previous comment (desc69): The integration in release601_fixes branch delivered also fix for issue 127672 "Frozen delete project action". The issue 127762 is about localization and has no relation (AFAIK) to this issue.
During testing of patch in release601_fixes branch was identified that there is new NPE, so I had to backport also changeset http://hg.netbeans.org/main/rev/e0e7a718d9ad "Unused property removed" to fix that. File web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/Attic/WebAppParseSupport.java revision 1.14.8.2 got this change.