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 do not know where yaml files are treated, feel free to reassign to scripting.. 20070816 ------------------------------------------- i noticed this long time ago. when i'm editing .yml file (mostly database.yml in rails), editor gets sometimes stuck for ~5-10sec. and completely stops to respond. This makes yml editing really painful. I also noticed some rendering lag-when i make some editing in file, it takes some time to correctly render syntax highlighting. Anyone else spotted this behavior? I can generate thread dump next time editor gets stuck...
i can reproduce 100% with: - start with fresh UD - open some rails project (i use depot application), choose jruby - doubleclick database.yml node (it takes a long time to open..) - file contains something like development: adapter: mysql database: depot_development username: someuser password: host: localhost - put the caret (i used mouse) to the end of host: localhost line - push enter for newline, type e.g. socket - i see only "s"...and i have to wait ~10 sec till "socket" appears rising to P2, since i found 100% reproducible steps (at least for me)
fixed in trunk: IDE:------------------------------------------------- IDE: [8/20/07 4:29 PM] Committing "Generic Languages Framework" started Checking in features/DatabaseManager.java; /cvs/languages/engine/src/org/netbeans/modules/languages/features/DatabaseManager.java,v <-- DatabaseManager.java new revision: 1.5; previous revision: 1.4 done Checking in features/SemanticHighlightsLayer.java; /cvs/languages/engine/src/org/netbeans/modules/languages/features/SemanticHighlightsLayer.java,v <-- SemanticHighlightsLayer.java new revision: 1.5; previous revision: 1.4 done Checking in features/Index.java; /cvs/languages/engine/src/org/netbeans/modules/languages/features/Index.java,v <-- Index.java new revision: 1.6; previous revision: 1.5 done Checking in ParserManagerImpl.java; /cvs/languages/engine/src/org/netbeans/modules/languages/ParserManagerImpl.java,v <-- ParserManagerImpl.java new revision: 1.37; previous revision: 1.36 done Checking in NBSLanguageReader.java; /cvs/languages/engine/src/org/netbeans/modules/languages/NBSLanguageReader.java,v <-- NBSLanguageReader.java new revision: 1.36; previous revision: 1.35 done Checking in EditorParser.java; /cvs/languages/engine/src/org/netbeans/modules/languages/EditorParser.java,v <-- EditorParser.java new revision: 1.4; previous revision: 1.3 done Checking in Language.java; /cvs/languages/engine/src/org/netbeans/modules/languages/Language.java,v <-- Language.java new revision: 1.47; previous revision: 1.46 done Checking in parser/LLSyntaxAnalyser.java; /cvs/languages/engine/src/org/netbeans/modules/languages/parser/LLSyntaxAnalyser.java,v <-- LLSyntaxAnalyser.java new revision: 1.41; previous revision: 1.40 done IDE: [8/20/07 4:30 PM] Committing "Generic Languages Framework" finished
sorry, but still reproducible (at least for the first time when file is opened) in some fresh build. Product Version: NetBeans IDE Dev (Build 200708290000) Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06 System: Linux version 2.6.20-16-generic running on i386; UTF-8; en_US (nb) Userdir: /tmp/ud
It took me more than one minute (Intel(R) Core(TM)2 CPU, T7200 @ 2.00GHz, 2GB Ram) to open database.yaml. Attaching thread dump.
Created attachment 48031 [details] threaddump.txt
Looking into the latest stacktrace I would say this is a duplicate of issue #114234 in particular of one of it's dependent issue #114747 (BaseDocument should be created rather for mimeType or EditorKit instance than for kitClass). I am sorry, but I think the fact that it took one minute is caused by running it in the profiler. In normal netbeans run it takes about 5-10 seconds as described in the issue above => decreasing priority. Reporter, if you can reproduce the time without profiler, feel free to upgrade to P1 again, thanks. I am leaving the final decision (if duplicate or not) on the issue owner. I am setting at least dependency meanwhile.
Please disregard the part of my comment about the profiler, the rest is valid. Thanks.
> Reporter, if you can reproduce the time without profiler, feel free to upgrade to P1 again, thanks. ... > Please disregard the part of my comment about the profiler, the rest is valid. Thanks. It is true that I've run it under *debugger*. Standalone IDE is about those 10s. So really P2. Probably dupe. However for yaml files it is enough to have 1kB.
I am also able to reproduce the problem with fresh user dir and it really takes over one minute, but I have suspicions that, in my case, this can be influenced by my overheating Toshiba - when CPU is running on 100% for a couple of seconds, its rate substantially slows down. When I asked Jirka Prox to reproduce the problem on his machine, the initial opening lasted for cca 4 seconds. Martine, do you also have Toshiba with similar performance as mine has? (well, I have just read that you run it under debugger) Additional evaluation of the issue: - I think the performance problem was improved for editing, editor does not get stuck for 5-10sec, I cannot reproduce these delays. The only exception is the problem mentioned by Marek, issue #114234, this is related to languages initialization and should appear only once. - As for the first time file opening, a small delay is reproducible for each language supported by Schlieman, it is caused by the language initialization. Moreover, during the one minute openings on my machine, most time is spend in org.openide.filesystems.FileUtil.createData method, not in Schliemann code. Decreasing priority to P2.
Aren't we mixing two issues togheter - 1] delay when file is opened 2] delay when you start editing?? ad 1] - i cannot reproduce the delay with the initial file opening - it takes ~3-4 sec on my desktop ad 2] - i *can* reproduce the delay using those steps i described. The delay is ~12sec.
I notice about a 12 second delay when I start editing this file. Since it's opened first, and since the user is likely to need to fix the password as the first thing they do, I don't think this delay is acceptable because it gives a bad first impression of Ruby editing. Is there any way to fix this delay?
Issue 114747 has been fixed for Schliemann. Now it seems that the first time editing of .yml files is responsive. Can someone another test it and confirm it?
confirmed responsivenes, anyway i noticed that syntax coloring is changed. Agreed to mark as fixed. Product Version: NetBeans IDE Dev (Build 200710100000) Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06 System: Linux version 2.6.20-16-generic running on i386; UTF-8; en_US (nb) Userdir: /tmp/ud
Ok, thanks, changing to fixed.