JavierSolis / resting

Automatically exported from code.google.com/p/resting
0 stars 0 forks source link

Transformation is slow in Android #9

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Transformation of the JSON response to VOs is slow for Android for a large list 
of VOs (>1000). This may be owing to the memory constraints of Dalvik VM as the 
DDMS logs show numerous GCs. The same works fine in ordinary Java platform. 

Original issue reported on code.google.com by sujata...@gmail.com on 4 Mar 2011 at 2:55

GoogleCodeExporter commented 9 years ago
GC logs below:

03-09 16:11:15.974: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 2815 objects / 
182688 bytes in 78ms<br>
03-09 16:11:27.025: INFO/System.out(911): JSONTransformer -- getResponseString 
took 22586 ms.<br>
03-09 16:11:27.823: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 4259 objects / 
152328 bytes in 93ms<br>
03-09 16:11:33.244: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 9358 objects / 
485192 bytes in 107ms<br>
03-09 16:11:39.345: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 10412 objects / 
491200 bytes in 95ms<br>
03-09 16:11:39.355: INFO/dalvikvm-heap(911): Grow heap (frag case) to 3.706MB 
for 125980-byte allocation<br>
03-09 16:11:39.475: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 0 objects / 0 
bytes in 120ms<br>
03-09 16:11:40.924: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 2361 objects / 
309368 bytes in 88ms<br>
03-09 16:11:41.014: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 3 objects / 112 
bytes in 92ms<br>
03-09 16:11:41.024: INFO/dalvikvm-heap(911): Grow heap (frag case) to 3.820MB 
for 140258-byte allocation<br>
03-09 16:11:41.124: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 2 objects / 93544 
bytes in 99ms<br>
03-09 16:11:41.234: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 4 objects / 234024 
bytes in 108ms<br>
03-09 16:11:45.444: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 1702 objects / 
413264 bytes in 107ms<br>
03-09 16:11:57.165: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 3341 objects / 
91208 bytes in 109ms<br>
03-09 16:12:11.785: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 4106 objects / 
110520 bytes in 122ms<br>
03-09 16:12:28.685: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 30776 objects / 
1259536 bytes in 147ms<br>
03-09 16:12:41.475: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 18601 objects / 
606872 bytes in 126ms<br>
03-09 16:12:54.444: DEBUG/dalvikvm(911): GC_FOR_MALLOC freed 18858 objects / 
616032 bytes in 134ms<br>
03-09 16:13:02.654: INFO/System.out(911): Time taken in transformation : 118286 
ms.<br>

I could conclude the following from the logs.

1. The average VO object (assuming the VO Objects are collected each time 
memory is freed) varies ~ 35 to 80KB. So the object size is not an issue.

2. The GC frequency is inceasing and lesser memory is freed each time are 
symptoms of a memory leak. 

3. The other possibility is that the application is using memory that it should 
ideally be using.

Recommended steps to fix the issue
===================================

1. Use DDMS and get a heap dump and track allocations. This can help to find 
memory leak if there is any.

2. If there are no memory leaks and application requires high heap values in 
case of large datasets, ncrease VM heap size (min, max) to 32M.

https://groups.google.com/group/android-porting/browse_thread/thread/a22a9bf2d67
013ac/6ffc46ab049a45a4?lnk=gst&q=heap+limit#6ffc46ab049a45a4

However, this solution is only stop-gap. We need to devise an approach to 
handle responses with large datasets (batching, callback, etc)

Original comment by lpriyapa...@gmail.com on 23 Mar 2011 at 5:17

GoogleCodeExporter commented 9 years ago
This issue is not happening anymore. Reassigning to Sujata to check this issue 
in device.

Original comment by lpriyapa...@gmail.com on 29 Mar 2011 at 4:00