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 46347 - MdrStorage$ValuesObject keeps many instances of the same Strings
Summary: MdrStorage$ValuesObject keeps many instances of the same Strings
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Martin Matula
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2004-07-20 16:31 UTC by Petr Nejedly
Modified: 2004-08-23 14:15 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 Petr Nejedly 2004-07-20 16:31:16 UTC
ValuesObject typically hold ~100 entries, vast
majority of them are Strings.
There is single instance of ValuesObject per
storage, and there are typically tens of storages
in the IDE (~17 with empty project, ~50 during
normal usage).

These ValuesObjects typically contain similar (or
identical) lists for the same type of storage,
but each instance has its own copy of these Strings.

With 50 storages, 100 Strings per storage and 25
characters per String, it means over 400KB wasted
just on the redundant instances of Strings.

It should be easy to postprocess the deserialized
array (and newly added objects) by replacing all
Strings with their intern() variant.

intern should be no problem here because of the
limited number of the Strings, most of which are
preinterned String constants anyway.

Additional (smaller, ~80KB) saving can be gained
by (quite simple) sharing of Integer instances as
well.
Comment 1 Petr Nejedly 2004-07-20 21:07:53 UTC
Very similar case is the StorablePackage class.
Again, there is one instance per storage and each of them holds
several maps with string keys, where the Strings are new copy each time.
The only difference is that this time the strings are generally shorter
(like "SwitchStatement", which is still 68B/instance)
This brings a potential for saving of another 7kb/storage
(>100 KB after startup, >300KB in common usage)

I'm slowly changing my mind about interning all strings ever created
by the IOUtils.read. It would be at least interesting test just to do
interning there and measure the impact on memory consumption (don't
forget to account perm consumption too, when comparing).
Comment 2 Martin Matula 2004-08-23 14:15:34 UTC
All strings deserialized using IOUtils are now interned.