Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 154512 - [67cat] Performance - Rename a TextField
[67cat] Performance - Rename a TextField
Status: VERIFIED FIXED
Product: guibuilder
Classification: Unclassified
Component: Code
6.x
All Windows XP
: P3 with 3 votes (vote)
: 6.x
Assigned To: issues@guibuilder
issues@guibuilder
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-03 17:03 UTC by stefan79
Modified: 2009-09-21 12:10 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
the jstack-l Logs (224.85 KB, application/x-compressed)
2008-12-03 17:05 UTC, stefan79
Details
Log-File (263.36 KB, text/plain)
2008-12-04 06:58 UTC, stefan79
Details
The GUI-FORM (6.78 KB, application/x-compressed)
2008-12-04 07:10 UTC, stefan79
Details
Stack-l while "private-renaming" (JTextField). The duration was 27 seconds (~jstack_l_1060.log - jstack_lg_1070.log). (50.12 KB, application/octet-stream)
2009-01-12 07:33 UTC, stefan79
Details
The Stacks. 1030-1130: Renaming a Label, 1150-1220: Renaming a JTextField. (807.92 KB, text/plain)
2009-01-13 08:00 UTC, stefan79
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. (671.25 KB, application/octet-stream)
2009-01-16 16:21 UTC, stefan79
Details
4 nps - Files: 2 renames on JTextField/JLabel (393.46 KB, application/x-compressed)
2009-01-26 17:35 UTC, stefan79
Details
89 Seconds renaming one JTextField (Build 200902110201) (89.08 KB, application/octet-stream)
2009-02-17 10:51 UTC, stefan79
Details
Profiler snapshot for rename (119.82 KB, application/octet-stream)
2009-04-15 19:33 UTC, misterm
Details
Rename label with Hibernate plugin disabled (249.92 KB, application/octet-stream)
2009-04-17 16:32 UTC, misterm
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stefan79 2008-12-03 17:03:19 UTC
Renaming a TextField takes up to 1-2 Minutes.

I made "jstack -l <pid>" - Loop.
The interesting Logs from Number 15.
Comment 1 stefan79 2008-12-03 17:05:09 UTC
Created attachment 74492 [details]
the jstack-l Logs
Comment 2 Tomas Pavek 2008-12-03 18:21:05 UTC
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.
Comment 3 stefan79 2008-12-04 06:58:35 UTC
Created attachment 74508 [details]
Log-File
Comment 4 stefan79 2008-12-04 07:09:35 UTC
-) 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
Comment 5 stefan79 2008-12-04 07:10:36 UTC
Created attachment 74510 [details]
The GUI-FORM
Comment 6 Tomas Pavek 2008-12-04 09:33:47 UTC
-) 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.
Comment 7 stefan79 2008-12-16 08:54:06 UTC
And now?
Comment 8 Jiri Vagner 2008-12-17 10:06:39 UTC
Now what? :) I can see only last comment from tpavek, there are two questions. I think that the ball is on your side now. ;)
Comment 9 stefan79 2008-12-17 12:28:24 UTC
> 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.
Comment 10 Tomas Pavek 2009-01-06 17:17:42 UTC
> 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.

Comment 11 stefan79 2009-01-12 07:30:33 UTC
>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.


Comment 12 stefan79 2009-01-12 07:33:44 UTC
Created attachment 75682 [details]
Stack-l while "private-renaming" (JTextField). The duration was 27 seconds (~jstack_l_1060.log - jstack_lg_1070.log).
Comment 13 Tomas Pavek 2009-01-12 16:56:50 UTC
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.
Comment 14 stefan79 2009-01-13 08:00:29 UTC
Created attachment 75736 [details]
The Stacks. 1030-1130: Renaming a Label, 1150-1220: Renaming a JTextField.
Comment 15 stefan79 2009-01-13 12:37:34 UTC
> 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.
Comment 16 Tomas Pavek 2009-01-16 15:59:00 UTC
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.
Comment 17 stefan79 2009-01-16 16:21:38 UTC
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.
Comment 18 stefan79 2009-01-26 17:35:25 UTC
Created attachment 76244 [details]
4 nps - Files: 2 renames on JTextField/JLabel
Comment 19 stefan79 2009-02-02 14:28:14 UTC
Do you need something more information?
Comment 20 stefan79 2009-02-17 10:51:17 UTC
Created attachment 77062 [details]
89 Seconds renaming one JTextField (Build 200902110201)
Comment 21 stefan79 2009-04-07 17:56:18 UTC
No response since Jan 16!?!

The nps - File should help you to find the performance-problem.
Comment 22 Tomas Pavek 2009-04-15 15:24:29 UTC
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.
Comment 23 misterm 2009-04-15 15:51:59 UTC
Rename works fast enough when it doesn't involve Matisse forms. It is still slow as from yesterday's build.
Comment 24 Michel Graciano 2009-04-15 15:57:28 UTC
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)
Comment 25 Tomas Pavek 2009-04-15 17:00:50 UTC
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
Comment 26 misterm 2009-04-15 17:03:52 UTC
> 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...
Comment 27 Tomas Pavek 2009-04-15 17:50:43 UTC
FYI just reminding the self-profiling feature: http://wiki.netbeans.org/FaqProfileMeNow
Comment 28 misterm 2009-04-15 19:33:15 UTC
Created attachment 80185 [details]
Profiler snapshot for rename
Comment 29 misterm 2009-04-15 19:36:33 UTC
Just added snasphot. Let me know if you need further info.
Comment 30 Tomas Pavek 2009-04-16 18:16:41 UTC
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.
Comment 31 misterm 2009-04-17 14:25:21 UTC
> 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.
Comment 32 misterm 2009-04-17 16:32:37 UTC
Created attachment 80372 [details]
Rename label with Hibernate plugin disabled
Comment 33 Tomas Pavek 2009-04-17 17:38:03 UTC
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...
Comment 34 misterm 2009-04-28 16:53:50 UTC
> 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.
Comment 35 Tomas Pavek 2009-05-12 13:15:01 UTC
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
Comment 36 Quality Engineering 2009-05-13 18:56:56 UTC
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
Comment 37 Michel Graciano 2009-05-13 21:07:33 UTC
It looks really better now. The refactoring is almost instantaneous to me. BTW, this patch has an regression as
described in issue #165110.
Comment 38 Tomas Pavek 2009-05-14 18:34:21 UTC
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.
Comment 39 Michel Graciano 2009-05-14 19:13:50 UTC
Thanks for quick fix in both issues. :-D
Tested in both Windows and Ubuntu workstations.

v. 200905140201
Comment 40 misterm 2009-09-17 15:53:27 UTC
Why has this issue been marked as NETWORK-DRIVE? At least for me and hmichel it happened on our notebooks' local file 
system.
Comment 41 Tomas Pavek 2009-09-21 12:10:18 UTC
There's really no indication this problem was related to network drives, removing the keyword.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo