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.
Renaming a TextField takes up to 1-2 Minutes. I made "jstack -l <pid>" - Loop. The interesting Logs from Number 15.
Created attachment 74492 [details] the jstack-l Logs
Thanks for the report with such detailed data. At the first sight some hibernate-related refactoring is suspicious, it is in more than half of the thread dumps. It is strange since the performed refactoring here should be just renaming a private field. Can you please also attach the 'messages.log'? So we know what exact modules you have installed. Can you confirm the textfield you rename is a private field in the code? Do you use it somewhere in the class - other than the generated parts? How big is the project (possibly other projects it depends on) where the GUI form is placed? Any chance you could attach it here or send us privately? Or at least the GUI form itself? Do you experience the same slowness if you create a new java project and a new GUI form in it (i.e. very small project)? Thanks for helping us to nail the problem down.
Created attachment 74508 [details] Log-File
-) I´ve attached the Log-File. -) The JTextField is a protected File (but not used) -) Project-Size ~6000 Source-Files -) I can´t attach the project, but I will attach the Form -) In a small project the renaming is a little bit faster
Created attachment 74510 [details] The GUI-FORM
-) The JTextField is a protected File (but not used) Does it help if you make it private (select the textfield, got to Code tab in properties)? -) In a small project the renaming is a little bit faster Was it also with 'protected' field, or private? For private fields the renaming should be almost instant. If it's not, there's some bug in refactoring. For a protected field the search for usages can take longer, depending on the size of the project (6000 files is quite a big project) - in such case the GUI Builder should probably invoke the standard Rename Refactoring dialog which is designed for long running operations.
And now?
Now what? :) I can see only last comment from tpavek, there are two questions. I think that the ball is on your side now. ;)
> I think that the ball is on your side now. ;) Sorry! > Does it help if you make it private (select the textfield, got to Code tab in properties)? I changed the modifier to private (compiled it) and then I renamed a Label and a TextField. Label: 10 seconds TextField: 12 seconds >> -) In a small project the renaming is a little bit faster >Was it also with 'protected' field, or private? I checked both (private/protected). Private is a little bit faster, but > 5 seconds.
> I changed the modifier to private (compiled it) and then I renamed a Label and a TextField. > Label: 10 seconds > TextField: 12 seconds That's much better than the originally reported 1-2 minutes. However, still too much. More than 5 seconds in a small project on private variable is also too much. I've tried the attached form and got instant renames... So - can you use the private variables in the GUI form? Should we go after optimizing those 10 seconds? In this case, could you also take some thread dumps during the rename? So we know what's happening in this case. Or do you rather want the protected variables rename fixed (the 1-2 minutes case) primarily? This is really hard to diagnose if we can't reproduce it and profile ourselves - it probably highly depends on your project.
>So - can you use the private variables in the GUI form? In some cases, yes. But not always. > Should we go after optimizing those 10 seconds? > In this case, could you also take some thread dumps during the rename? > So we know what's happening in this case. I´ll attach the Zip-file in some Minutes. > Or do you rather want the protected variables rename fixed (the 1-2 minutes case) primarily? > This is really hard to diagnose if we can't reproduce it and profile ourselves - it probably > highly depends on your project. Let´s do the first problem (private-Renaming) and then I´ll test the protected-Renaming again.
Created attachment 75682 [details] Stack-l while "private-renaming" (JTextField). The duration was 27 seconds (~jstack_l_1060.log - jstack_lg_1070.log).
The attached logs are empty... BTW we'll have a "self-profiling" feature in the IDE soon which you could use to give us more detailed snapshot of what is happening. More here: http://wiki.netbeans.org/FitnessViaPartnership But for now, the more thread dumps you can give, the better.
Created attachment 75736 [details] The Stacks. 1030-1130: Renaming a Label, 1150-1220: Renaming a JTextField.
> The attached logs are empty... Sorry! > BTW we'll have a "self-profiling" feature in the IDE soon which you could use to > give us more detailed snapshot of what is happening. More here: http://wiki.netbeans.org/FitnessViaPartnership Fine feature but is this feature also in 7.0m1? Because the IZ (http://openide.netbeans.org/issues/show_bug.cgi?id=153221) isn´t closed and I can´t find a button/Shortcut/description how this should work.
Again, even in the case of only renaming a private variable, there's lots of hibernate-related refactoring running, taking most of the time in this case. In the GUI form itself you have no hibernate stuff, right? Do you use it in your project? To verify, can you try to go to Tools | Plugin Manager, select "Installed" tab and uninstall the hibernate support, restart the IDE and test if the performance improved? As for the self-profiling feature, it is not integrated yet, but hope to have it soon. You can watch the issue 153221.
Created attachment 75910 [details] I don´t need Hibernate. I´ve deactivated the plugin and restarted the IDE and was waited some Minutes. Then I rename a JLabel (Log 1102-1127) ~ 12 Seconds, and then a JTextField (Log 1193-1219) ~ 10 Seconds.
Created attachment 76244 [details] 4 nps - Files: 2 renames on JTextField/JLabel
Do you need something more information?
Created attachment 77062 [details] 89 Seconds renaming one JTextField (Build 200902110201)
No response since Jan 16!?! The nps - File should help you to find the performance-problem.
Sorry for delay, I thought I answered already but apparently did not... The profiling snapshots revealed that a lot of time is spent in native filesystems methods, especially in WinNTFileSystem.getBooleanAttributes. Overall it does not seem the IDE would be doing too much, it seems like the whole filesystem was very slow. This also matches the reported slowness of renaming even in a small project and on private field - it indicates the problem is not in refactoring processing too much data. BTW is any other Rename refactoring (not involving GUI forms) slow too? We know getBooleanAttributes is used a lot and is costly, but it seems really extreme in this case. We saw a few similar problems reported, but never managed to reproduce it reliably or find out what exactly is wrong. See e.g. issue 151339 or issue 156652. There are some hypothesis that the culprit might be broken shortcuts (invalid links) or big zip files on the desktop. Using a different (newer) JDK version might help too. Can you check? Also for NB 6.7 the code for scanning/indexing changed a lot in last two months, so would be worth trying a latest daily build (it's very close to beta right now). A very simple test case to try for you: Create a new Java project (on a local disk, not under version control). Create a new GUI form in it. Add a component, save. Rename the component. Does it still take 10+ seconds? Then try your usual working project. Any additional info you can provide on this issue would be helpful. Sorry I don't have better advice for you at this moment. I'm lowering priority since the slow getBooleanAttributes seems to happen quite rarely.
Rename works fast enough when it doesn't involve Matisse forms. It is still slow as from yesterday's build.
I have the same problems on Ubuntu. Renames take a long time several times, sometimes more than 1 minute. Product Version: NetBeans IDE 6.5 (Build 200811100001) Java: 1.6.0_11; Java HotSpot(TM) Client VM 11.0-b16 System: Linux version 2.6.27-14-generic running on i386; ISO-8859-1; en_US (nb)
misterm, hmichel - could you create a profiling snapshot and provide more info about what exact renaming you're doing? Note we are mostly interested in renaming a component in a GUI form (component having private field, all scanning finished). Thanks
> Note we are mostly interested in renaming a component in a GUI form (component having private field, all scanning > finished). That's exactly the kind of refactoring I'm performing. Profiling snapshot coming later...
FYI just reminding the self-profiling feature: http://wiki.netbeans.org/FaqProfileMeNow
Created attachment 80185 [details] Profiler snapshot for rename
Just added snasphot. Let me know if you need further info.
Thanks for the snapshot. It shows the renaming took 120s. Almost 80% of time seems like accessing slow filesystem again, specifically FileInputStream.open (native method) in this case. Really don't know why the operation of opening file input should take so long. You don't have the sources on network, do you? Can you confirm rename refactoring is not slow if GUI form is not involved? Could you rename a field in a class that is not a GUI form and create a snapshot from that? (Note need to start profiling before invoking the dialog.) There's a lot of hibernate refactoring involved (not sure why - do you use hibernate)? Could you check if disabling hibernate support helps? Still it does not explain the extreme slowness of FileInputStream.open, without hibernate there would be just less calls of it.
> You don't have the sources on network, do you? No. > Can you confirm rename refactoring is not slow if GUI form is not involved? It isn't, it's instantaneous. > Could you rename a field in a class that is not a GUI form and create a snapshot from that? It wouldn't help much, since the IDE does instant renaming, which is different. BTW, why doesn't Matisse use instant rename for private fields? > There's a lot of hibernate refactoring involved (not sure why - do you use hibernate)? I use Hibernate 2.1.8, but no feature from the plugin > Could you check if disabling hibernate support helps? It helps, but it's still unacceptable. See the attachment.
Created attachment 80372 [details] Rename label with Hibernate plugin disabled
Without hibernate it is much faster, but still slow - 30s vs 120s. In this case the slow filesys is not that apparent (FileInputStream.open, WinNTFileSystem.getBooleanAttributes, etc) - about 30%. Parsing the java file (or more files?) takes long here. Also the parsing seems to be done twice (once from AbstractRefactoring.pluginsPrepare, once from AbstractRefactoring.checkParameters) - 17s together. Another big chunk is resolving the fully qualified names of the regenerated code - 11s (BTW this can be turned off). How big is the form you tried (how many lines of code, components)? Does it contain custom components (not from JDK) - i.e. dependencies to other sources? I'm trying to figure out if it is really so complex java file/project for such long parsing. Perhaps we should try to find a way to rename private components in a more efficient way than running through the complete rename refactoring. E.g. get inspired by the instant renaming in editor. Still, I don't see why the rename refactoring should be so much slower - that should be fixed too. I wish we could reproduce this...
> How big is the form you tried (how many lines of code, components)? LoC: 1249 Components: 91 Just tried a rename on a new form (JDialog) with a single JButton. Hibernate turned on: 1min20sec Hibernate turned off: 4sec As I added more JButtons (up to 50), it got slower (6sec). After adding 10 custom components, it takes from 30 to 40 sec. > Does it contain custom components (not from JDK) - i.e. dependencies to other sources? Yes, it does. > Perhaps we should try to find a way to rename private components in a more efficient way than running through the > complete rename refactoring. E.g. get inspired by the instant renaming in editor. Still, I don't see why the rename > refactoring should be so much slower - that should be fixed too. Please, please, please do it. It is our major pain using Matisse.
I somewhat managed to reproduce the situation when the rename was slower (got about 4s) in a GUI form that was part of a big project and contained references to other classes in the project. For some reason the full RenameRefactoring need to resolve all that, so it can be slow. I've implemented a simple rename for private fields that does not use the refactoring (similar to editor's in-place rename). I've got almost instant response compared to the original 4s. Please verify this fix once it appears in a daily build (notification appears in this report). Then a bug should also be filed on Hibernate refactoring - so the general RenameRefactoring can be improved too. Would be good to attach there a new profiling snapshot (after this fix) - could be created by renaming a protected or public component field (which will go through full RenameRefactoring and expose all the time spent in hibernate). http://hg.netbeans.org/cdev/rev/ecb13967ea94
Integrated into 'main-golden', will be available in build *200905131401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ecb13967ea94 User: Tomas Pavek <tpavek@netbeans.org> Log: #154512: don't use RenameRefactoring on private fields
It looks really better now. The refactoring is almost instantaneous to me. BTW, this patch has an regression as described in issue #165110.
Good to see the fix helps. Thanks for catching the new bug. BTW I've created a new issue on the Hibernate refactoring - issue 165206.
Thanks for quick fix in both issues. :-D Tested in both Windows and Ubuntu workstations. v. 200905140201
Why has this issue been marked as NETWORK-DRIVE? At least for me and hmichel it happened on our notebooks' local file system.
There's really no indication this problem was related to network drives, removing the keyword.