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 31593 - Closing large .properties file takes a long time and seems to leak memory
Summary: Closing large .properties file takes a long time and seems to leak memory
Status: VERIFIED FIXED
Alias: None
Product: utilities
Classification: Unclassified
Component: Properties (show other bugs)
Version: 3.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: issues@utilities
URL:
Keywords: PERFORMANCE, UI
Depends on:
Blocks: 32123 32129
  Show dependency tree
 
Reported: 2003-02-28 20:37 UTC by jbisotti
Modified: 2003-12-11 14:25 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jbisotti 2003-02-28 20:37:38 UTC
I have a .properties file containing all of my
applications text resources; about 3450 lines and
~131KB in size.  Using the default settings,
opening it takes several seconds; and there are
several longs pauses using the arrow keys to
position the cursor (very painful).  Recently, I
added the following settings to my ide.cfg and I
have seen great improvement in these two areas.

-J-Xms64m
-J-Xmx128m
-J-XX:+BackgroundCompilation
-J-XX:CompileThreshold=100
-J-Xverify:none
-J-XX:+UseConcMarkSweepGC
-J-XX:+UseParNewGC
-J-XX:PermSize=20M
-J-XX:+CMSParallelRemarkEnabled
-J-XX:MaxTenuringThreshold=0
-J-XX:SurvivorRatio=128
-J-XX:NewSize=4M
-J-XX:MaxNewSize=4m

HOWEVER, a couple of issues still remain.  First
off, closing the file still takes ~8 seconds. 
Secondly, it seems like there might be a memory leak.

Following, are the steps/results I got with a 3.5
Q-Build from last week.

1. Start NetBeans.
2. After it comes up, press the GC button on the
memory toolbar several times to collect as much
memory as possible.  I got down to 10.5MB of 64MB.
3. Find the .properties file.  In my case, I have
a Label.properties file and several NLS versions
so I expand the node, select "Default", bring up
the context menu and choose "Edit".
4. After the file is opened, my memory bar reports
18MB of 64MB.
5. Press the GC button on the memory toolbar
several times to collect as much memory as
possible.  I got down to 12.5MB of 64MB
6. Click on the 'x' on the files tab to close it.
7. Wait 8 seconds for file to close.
8. After the file is closed, my memory bar reports
68MB of 114MB.
9. Press the GC button on the memory toolbar
several times to collect as much memory as
possible.  I got down to 26MB of 114MB.  Almost
16MB more being used that before I opened the file.
10. Repeat the opening and closing process again.
 This time, after pressing the GC button several
times, I was only able to get down to 64MB of 131MB.
Comment 1 _ pkuzel 2003-03-03 10:32:03 UTC
I guess you work with default table view. It automatically parses all
locales so the memory model can be pretty large. Going to investigate
the leak.
Comment 2 _ pkuzel 2003-03-06 14:05:10 UTC
I have not yet evaluted on memoty leak but:

Dusan I guess it's big candidate on HIE review. Why the table contains
all collumns. Would not it be enough to have three: key, selected
locale 1 and selected locale 2. Having 2 combos to allow select locales.

It would help USABILITY and PERFORMANCE.
Comment 3 _ pkuzel 2003-03-24 14:41:06 UTC
I'm able to reproduce the slowness problem on closing text editor.

org.netbeans.editor.DocumentContent.createBiasPosition(DocumentContent.java:91)
org.netbeans.editor.BaseDocument.createPosition(BaseDocument.java:851)
org.openide.text.NbDocument.createPosition(NbDocument.java:155)
org.openide.text.PositionRef$Manager$Kind.toMemory(PositionRef.java:414)
org.openide.text.PositionRef$Manager.addPosition(PositionRef.java:337)
org.openide.text.PositionRef.init(PositionRef.java:81)
org.openide.text.PositionRef.<init>(PositionRef.java:76)
org.openide.text.PositionRef.<init>(PositionRef.java:53)
org.openide.text.CloneableEditorSupport.createPositionRef(CloneableEditorSupport.java:750)
org.netbeans.modules.properties.PropertiesParser.createBiasBounds(PropertiesParser.java:321)
org.netbeans.modules.properties.PropertiesParser.readNextElem(PropertiesParser.java:299)
org.netbeans.modules.properties.PropertiesParser.parseFileMain(PropertiesParser.java:160)
org.netbeans.modules.properties.PropertiesParser.parseFile(PropertiesParser.java:115)
org.netbeans.modules.properties.StructHandler.reparseNowBlocking(StructHandler.java:76)
org.netbeans.modules.properties.StructHandler.reparseNowBlocking(StructHandler.java:60)
org.netbeans.modules.properties.PropertiesEditorSupport$PropertiesEditor.closeLast(PropertiesEditorSupport.java:852)

I'll have to take closer look on model synchronization mechanism.
Comment 4 _ pkuzel 2003-03-25 13:06:01 UTC
I did some optimalizations such as that text editor usage will never
provoke populating structure model. It eliminates long pauses during
editing.

I cannot reproduce the memory leak.
Comment 5 pfelenda 2003-03-28 16:17:20 UTC
Verified in dev 200303270100.
Opening file spent 3 sec.
Closing file spent 1 sec.
File had 3500 properties with comments. I tried this on 
1000 MHz processor and 384 MB RAM on Linux.