Ideas to reduce memory usage [message #1017194] |
Mon, 11 March 2013 03:00  |
Luke V Messages: 3 Registered: February 2013 |
Junior Member |
|
|
I'm using Sapphire to facilitate an XML entry for a design description and documentation format. The XML schema is rather complex (has many levels of hierarchy and is composed of multiple files). The schema comes from an standards committee and I cannot modify it for simplification.
I have a sapphire form/model put together and it works well for smaller xml files (< 256K). However as the files get larger, the load time grows and the memory usage starts to balloon. For a larger xml file (1-2MB), the load time opening the first form is a minute or two and eclipse's memory usage creeps into the 1200MB to 1500MB range. This tends to make eclipse less than responsive (even on a recent desktop machine with 12GB of RAM) and decreases the editor's usefulness. Sapphire 0.5x series would crash the JVM with the larger files. Sapphire 0.6 eventually loads, but is very slow. I've tried all sorts of JVM configuration tweaks, 1.6, 1.7, Hotspot, OpenJDK, and both Eclipse Indigo and Juno without any luck.
I've tried analyzing the issue a bit with the various memory profiler tools. From an initial look, it seemed that much of the utilization was due to creating a new service object for each node in the design. One quick idea was to try and figure out how to share a service object (or have a default one) for nodes that didn't customize the service at all. However, this seemed to be a bit of work (especially without a good working knowledge of Sapphire's internals).
Does anyone have an additional insight or ideas of how to reduce memory usage on designs with large numbers of model nodes?
|
|
|
|
|
|
|
|
|
Re: Ideas to reduce memory usage [message #1064579 is a reply to message #1064561] |
Thu, 20 June 2013 05:28   |
Luke V Messages: 3 Registered: February 2013 |
Junior Member |
|
|
MasterConversionService has definitely been driven off the radar... Thanks for your expedient patch! Memory usage is down to 685MB (total for eclipse) from 700MB for the 1.5MB XML file. Looking at the memory analyzer again, there looks like there might be some more low hanging fruit... (I guess the term low hanging is relative judging from the 100 files updated for 85a2748... )
Currently on the top of the "Biggest Top-Level Dominator Classes" list is org.eclipse.sapphire.services.internal.PropertyInstanceServiceContext. Digging into the dominator tree for this object, org.eclipse.sapphire.modeling.el.Literal$1 floated to the top.
In the current model/file that I am using, there ends up being 326,153 instances of these Literal objects. A couple of interesting stats that I noticed about these literals:
1. There are 68217 literals with the value of null, each taking up 376 bytes = ~25MB of "nulls". I haven't had the chance to trace the origin or study if any of these "nulls" are used for the Function.origin members instead, but at a first glance, it would seem that these have the potential to be replaced with the same static copy of Literal.NULL
2. For a literal text value of "false" 520 bytes are retained by the literal object. (376 of these being the literal's overhead). 144 bytes of storage for a 5 character string seems bit off (a bit of googling and some math seems to indicate that this should be 56 bytes for a fresh string.). Also, I noticed that the Literal class had true/false static values which might be of service here (although this will probably take some tweaking on the model to get the data types to be translated through the model correctly).
2. There are 2686 copies of the following literals (each 1032 bytes) for a total of ~2.5MB. Appears at first glance to be ab bit redundant...
<html><head><style>body
{
margin: 0;
overflow: auto;
}
table
{
border-width: 0px;
border-spacing: 0px;
border-collapse: collapse;
}
td
{
margin: 0px;
padding-right: 10px;
}
body, td
{
font-family: "Segoe UI", "sans-serif";
font-size: 9pt;
}
</style></head><body>
Will do some more memory analyzer digging later...
[Updated on: Thu, 20 June 2013 05:30] Report message to a moderator
|
|
|
|
Powered by
FUDForum. Page generated in 0.02782 seconds