Re: [Sisc-users] SISC on Android and the Heap

[Scott G. M. <sgm...@gm...>]

BTW, have you tried the SISC-lite heap?  It contains only whats needed for
R5RS Scheme, and might be faster.  You can build it with 'ant clean; ant
lite-heap'.  This will build new SISC jars as well.

Scott

On Sat, Mar 6, 2010 at 1:41 PM, Scott G. Miller <sgm...@gm...> wrote:

> Unfortunately, what seems to be left are just a really high number of calls
> to read().  On desktop Java, these are pretty cheap since they're compiled
> down to native code.  Apparently Dalvik doesn't do nearly as well.  There
> isn't really any way to avoid reading in that data, as most of SISC is
> implemented in Scheme.  What would be ideal (but Java lacks) would be the
> ability to map a large block of Java heap to and from a file directly.
>
> Scott


>
> On Sat, Mar 6, 2010 at 10:49 AM, Chad Albers <ca...@ne...>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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>