Re: [Sisc-users] SISC on Android and the Heap
Brought to you by:
mradestock,
scgmille
Menu
▾
▴
Re: [Sisc-users] SISC on Android and the Heap
|
From: Nikita S. <nik...@ma...> - 2010-03-10 04:05:44
|
Hi Chad,
Your profiler data suggest that it takes 0.223 millisecond per call of MemoryRandomAccessInputStream.read(). But the method is really simple:
public int read() throws IOException {
if (filePointer==data.length) return -1;
return data[filePointer++] & 0xff;
}
Being called 35K+ times results in 7 seconds spent just calling this method.
Are you sure it's not the profiler or the simulator that make thing so slow? Have you tried to run it on a real device? Or at least in the simulator but without profiler enabled?
Nikita
On 03/06/2010 11:49 AM, Chad Albers wrote:
> Hi Scott,
>
> I made the changes that your recommended, and removed the dependencies the ber encoding, and rebuilt the heap. There's a slight performance improve. On my emulator, it now takes 15 seconds to add 3 plus 4. It takes a full minute to instantiate a web view, add markup to it, and then query it's title (that's down 15 seconds).
>
> Here' are the new results from the profiler: http://www.neomantic.com/images/screenshot3.png - this is for the instantiate example. You can see that ber encoding is no longer used. The blockage still seems to me to be the ser.* classes.
>
> Do you have any other advice for further optimizations?
>
> Chad
>
> --
> Chad Albers
> http://www.neomantic.com
> (pgp signature available on request)
>
>
> On Thu, Mar 4, 2010 at 6:07 AM, Scott G. Miller <sgm...@gm...> wrote:
>
> Yes, you have to rebuild the heap file after that.
>
> Scott
>
>
> On Wed, Mar 3, 2010 at 8:25 PM, Chad Albers <ca...@ne...> wrote:
>
> Hi Scott,
>
> Thanks for the advice. The heap I'm using is from the latest cvs, and it was built using the ant task. If I'm going to change that code as described below, I should probably recreate the heap, right?
>
> I made those changes, and now I get a message saying there is an error loading heap.
>
> Chad
>
>
> --
> Chad Albers
> http://www.neomantic.com
> (pgp signature available on request)
>
>
> On Wed, Mar 3, 2010 at 9:12 AM, Scott G. Miller <sgm...@gm...> wrote:
>
> The BerEncoding classes were actually what I suspected might be the problem. They're fairly cheap on desktop processors, which can do multiple arithmetic operations per clock cycle, but may be worse on embedded processors which can't.
>
> You might try changing the implementation of readInt in DeserializerImpl to just datin.readInt(), and writeInt in SerializerImpl to datin.writeInt(). This would use a bit more space in the heap but save cycles.
>
> Are you building the heap with "ant heap" in the source distribution?
>
> Scott
>
>
> On Tue, Mar 2, 2010 at 8:26 PM, Chad Albers <ca...@ne...> wrote:
>
> Hi Scott,
>
> I did try to create the heap manually by following what happens in GenerateHeap.java, just in case building it was quicker than deserializing it. The build failed.
>
> I took your advice about the profiler. Android, indeed, has one called traceview (http://developer.android.com/guide/developing/tools/traceview.html). I don't' have much experience with profilers, so the information is murky to me. I set up a trace around line 173 in AppContext.java where r.eval("(initalize)"); is called. Here's as screen shot: http://neomantic.com/images/traceview.png
>
> I sorted by 'Exclusive' time, the time inside a method, java.io.DataInput comes in on top, but it really has to do with sisc/ser/BerEncoding.readBerLong, the 2nd one, one of those sisc.ser.* classes. But I may be reading this wrong.
>
> Do these results tell you anything? Got any advice on what I should be looking for?
>
> Thanks for your help,
>
> Chad
>
>
> --
> Chad Albers
> http://www.neomantic.com
> (pgp signature available on request)
>
>
> On Mon, Mar 1, 2010 at 11:25 AM, Scott G. Miller <sgm...@gm...> wrote:
>
> On Sun, Feb 28, 2010 at 6:22 PM, Chad Albers <ca...@ne...> wrote:
>
> I've been plugging away on getting SISC to work on Android, and made more progress. But I've hit a major obstacle: serialization and deserialization is notoriously slow on Android. Really slow. Embedded inside a Android App, SISC takes about 45 seconds to run a simple eval on the emulator. Most of that time is spent on (initialize) - which performs a lot of deserialization on the precompiled heap file.
>
> My question is can I operate SISC in some way without using the precompiled heap, and instead loading in the code precompiled in the heap. Scott Miller's 2002 paper seems to imply that this is possible, provided you're willing to take a 10-15 sec performance hit (page 5).
>
>
> The alternative to the heap is to load all the startup code from scratch, which is way slower (by about an order of magnitude). It may be possible however to sacrifice some space (ie a bigger heap) and use a different encoding. Does the Android platform have a profiler? Seeing where the bulk of the time is spent during startup may help suggest a different heap storage strategy.
>
>
> Even if I manage this task, my next question is how often does SISC use serialization/deserialization during processing...(I suspect a great deal).
>
>
> Code is lazily loaded in using ser/deser during operation, yes, but the bulk of R5RS is available when you hit the prompt.
>
> Scott
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
> _______________________________________________
> Sisc-users mailing list
> Sis...@li...
> https://lists.sourceforge.net/lists/listinfo/sisc-users
>
|
