Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Message-ID: <29973608.1198748443012.JavaMail.jira@brutus>
Date: Thu, 27 Dec 2007 01:40:43 -0800 (PST)
From: "Christiaan (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Subject: [jira] Created: (OPENJPA-474) Memory overhead by openjpa
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Memory overhead by openjpa
--------------------------

                 Key: OPENJPA-474
                 URL: https://issues.apache.org/jira/browse/OPENJPA-474
             Project: OpenJPA
          Issue Type: Bug
         Environment: Windows XP, Kodo 4.1.4, Sun JDK 1.6.2, ms sql server 2005, JTDS driver
            Reporter: Christiaan


I am doing some analysis for the memory usage since we are running into a couple of problems in our project when doing import of large quantities of objects. I've created a simple testcase which does the following: 

1) Create all objects (2 classes, one class with 5 string attributes, the other is embedded and has no attributes); 
2) Call makePersistent() on the objects; 
3) Call commit(); 

The results: 
- After step 1) takes up 23 mb of memory in the testcase; 
- After step 2) the memory usage has increased to 191 mb. Actually there are 3 scenarios I used: 
1) Creating objects without the embedded class (which has no attributes, just an empty class): 75 mb 
2) Creating objects with the embedded class instantiated: 180 mb; 
3) Creating objects with the embedded class instantiated and after makePersistent() again instantiated (overwriting the previous value): 191 mb 
- During step 3) commit() the memory usage peaks at 580mb 

So, 
1) to persist objects which take up 23mb of memory, a total of 580mb so giving a memory overhead of a factor 25 by the openjpa! 
2) maintaining the datastructure whether objects are persistent increases the memory with a factor of 4 to 8, depending whether embeddable objects are used; 
3) "overwriting" embedded objects within a transaction, the previous embedded object still seems to take up some memory; 

I haven't done a thorough analysis on this but some interesting things I noticed from the profiler: 
1) One of the hotspots is in storing the RowImpl._sql. If I am not mistaken, this sql is stored (cached) for each object to be inserted. So in large transactions where a lot of similar objects and modifications are involved, this is quite a duplication which leads to unnecessary memory overhead. Of course there is a performance gain of caching it, but may be this should be better balanced with memory usage?; 
2) Though I've set kodo.Log=none there is a hotspot in LoggingConnectionDecorator? Is this decorator used for something else as well or is this a bug? I removed it in code from DecoratingDatasource and this reduced the total memory usage to 500mb 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.