[Tfug] OT: Phones..... Argh!

[John Gruenenfelder]

On Fri, Mar 22, 2013 at 3:49 AM, Bexley Hall <bexley401 at yahoo.com> wrote:
> Hi John,
>
>> I had considered this route as well, but it seems to have only a
>> minimal effect.  Whether this is due to my device's underlying problem
>> or due more to how Android operates (normally or under memory
>> pressure) I can't really say.
>
>
> Once "responding", does it process keystrokes (or whatever other
> "events") quickly?  I.e., does it look like there is just some
> large "front-loaded" delay after which things move along normally?
> Or, does it look like the processor is running at half/third/etc.
> speed?  Like continually "thrashing" or being preempted by
> some "nuisance"?

Yup, when it would go out to lunch temporarily, this is how it would
behave.  Before I learned to recognize it and just wait, i would
sometimes attempt an activity several times, like trying to dial a
number.  When it would finally start processing events again, it would
suddenly do them all in rapid succession, probably handling them as
fast as it could at that point.  Suddenly, the phone is (or is trying)
to make three outbound calls and while I'm trying to sort it all out,
the first call is answered and I'm still trying to cancel the others.

>> But, as I said, it does help a little.  If I start something large and
>> known to be slow, such as the Amazon app store, letting it sit for
>> 15-30 seconds before trying to use it will make it slightly more
>> bearable.  This doesn't always work, though.  Trying to use Firefox
>> tends become slower as time passes... same for the built-in Browser
>> app.
>
> <frown>  Speaking entirely from ignorance <grin> that *sounds* like
> a memory issue.  I.e., the cost of visiting a URL should remain
> the same -- regardless of how long Firefox has been running.  What
> is likely to change, over time, is how much memory has been consumed
> and.or how heavily fragmented memory is becoming (making it harder
> to satisfy memory allocation requests... leading to more GC activity,
> etc.)

Indeed, it very much *seemed* that this was the cause, but I suspected
an alternative cause (or maybe a few things working in tandem) since,
for example, Firefox (or the stock Browser) would quickly go downhill,
getting slower and slower.  If I was quick, I could exit the app, but
if I attempted to keep using the app the inevitable result would be
the phone resetting itself.

Now, however, I have followed the link Nick provided and installed
Android 4.2 (Cyanogenmod 10.1) and any slowness I experience is
definitely caused by low memory issues.  It *can* be sluggish, but it
feels and behaves just like a low memory state now.  For apps which do
not require a lot of RAM, on the other hand, the performance can be
very nice.

>> I'm looking forward to trying one of the Android 4.2 nightlies to see
>> how big a difference there is in performance, or, at least, perceived
>> performance.  :)
>
> It's just hard for me to imagine something with that much horsepower
> being that *sluggish*!  Unless there are power conservation issues
> that are getting in the way (e.g., if it has to power down regions
> of memory not in currently use.... or, demand load pages from secondary
> storage *when* needed, etc.)

Isn't it? There is a lot going on where Android meets the Linux kernel
on these devices.  A great deal of power saving tasks, a lot of work
done to make the Dalvik Java layer behave well/fast while still
keeping each app away from the others, and so on.

On my Droid 3, it has always reported total RAM as 393 MB, but that
can't be right.  It must be 512 MB with 100+ being dedicated to things
I can't touch, perhaps video/3D buffers?  Still, you would think that
393 MB of RAM *ought* to be enough for good performance.

You mentioned secondary storage... I'm sure that has a noticeable
effect, too.  The *internal* flash storage is emmc based and then, on
this device, there is another 16 GB of "internal SD storage" which is
probably some cheaper/slower type of flash.  Then there is the 16 GB
microSD card I added and I know the throughput on that can't be
superb.

> In your reply to Nick, you mentioned "LBE"s role.  Do you know *how* it
> is implemented?  I.e., does it "hook" the portions of the API that would
> normally be used to access "private data" and conditionally filter
> them based on its current configuration?  (In which case, it should
> only have an impact on those particular calls!)   Or, does it sit
> and examine executing threads to see where they are poking around
> (in which case, it could slow down *everything*)?

If I recall correctly, it did hook into the API in some manner to do
its job.  As far as I know, this is the only way it could have
intercepted an app's access to certain data and/or the network.  It
would also explain why LBE never appeared to be having any effect on
system performance according my process viewer/manager.

Since it was hooking into the API rather than going the heavy handed
route of continually monitoring the system, it would stand to reason
that it should be quick at its work.  Unfortunately, that doesn't
appear to have been the case since when I uninstalled it (while still
running Android 2.3.4) the device immediately started running far far
better.  I didn't even need to reboot it.

I didn't want to get rid of LBE because it allowed me to use almost
any app on the Market and not worry much about what permissions/data
it wanted access to since I could always override it.  But, LBE
doesn't work with Android 4+ so I would have had to get rid of it
eventually.  I'll just need to be more selective about what I install.
 In particular, I often download the Amazon "Free App of the Day"
since it is, well, free.  Even though these are pay apps free for one
day, many still have a laundry list of requested permissions.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for Palm OS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max