search

AlmightyMegadeth00 / apv

Automatically exported from code.google.com/p/apv
GNU General Public License v3.0
0 stars 0 forks source link

High memory usage #26

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Read lots of PDF files
2. See other programs being killed and RSS of apv > 120MB

What is the expected output? What do you see instead?
Memory usage should stay at 50MB

Please use labels and text to provide additional information.

I've started to look at memory allocations with DDMS. And in
PagesView.java, making "Rect r1" static for rectsintersect() helps: each
time the GC is run, only 50 objects are removed instead of 200+.
Do you think it's safe to make r1 static ?

Original issue reported on code.google.com by ldro...@gmail.com on 30 Apr 2010 at 6:03

GoogleCodeExporter commented 9 years ago 
Here are some procmem outputs. You'll see lots of MB allocated in
/dalvik-heap-bitmap/mark/2 and /dev/pmem_camera (strange ? apv does nothing 
with the
camera ?!). On the emulator I see the same leaks except for /dev/pmem_camera. 
The leaks cannot be seen in the DDMS VM heap monitor, so it might be a system 
bug...

Original comment by ldro...@gmail.com on 1 May 2010 at 8:50

Attachments:

GoogleCodeExporter commented 9 years ago 
Would it be possible to reduce the memory usage by supporting viewing in 
monochrome? For most text PDF document, color is not needed. Further more, APV 
uses RGBA all the time and most devices do RGB565 only. Would this help on the 
rendering performance too?

Original comment by yuanc...@gmail.com on 6 Mar 2011 at 12:28

GoogleCodeExporter commented 9 years ago 
The change from RGBA to RGB_565 has indeed been made.

I also added a grayscale option.  I don't see any performance improvement with 
it, but I suppose it decreases memory usage.

Original comment by arpruss on 27 Jul 2011 at 3:04

GoogleCodeExporter commented 9 years ago 
I also experimented with compressing the tiles.  Using Android's png 
compression was too slow.  But I think that so many pdfs are full of blank 
space that one could write short native-code run-length 
decompression/compression routines that would help a fair amount on most tiles.

Original comment by arpruss on 27 Jul 2011 at 3:40

GoogleCodeExporter commented 9 years ago 
This has something to do with image rendering.  On an image-heavy document, I 
see 7-8 mb added to the memory usage each time I go down a page.  This is 
obviously way more than our cache holds.  And it doesn't get freed when you 
load another document.

I think mupdf is caching data.

Original comment by arpruss on 31 Jul 2011 at 3:45

GoogleCodeExporter commented 9 years ago 
I fixed the leaks.  There were three: 
 1. allocation of pages
 2. pdf->glyph_cache
 3. pdf->xref

The big one was pdf->xref->store.  To prevent uncontrolled growth, I now kill 
the store after every tile render.  A better way to proceed would be to age it 
gracefully, but I will leave that for later optimization.

Original comment by arpruss on 31 Jul 2011 at 7:46