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

[Bexley Hall]

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.

Sure *sounds* like an initialization/startup problem!  <shrug>
E.g., allocating memory, resolving late bindings, etc.

>>> 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.

So, the previous problem has "gone away"?

>>> 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?

Processors keep getting *faster* and code keeps getting *slower*!
"Progress".  <frown>

I'd always used ~300ms as the threshold of *pain* regarding
user feedback.  Targeting *50ms*, instead, so folks never get
the "apprehension" that comes with interfaces that are always
(or even *sometimes*) sluggish -- forcing them to watch and
wait for acknowledgement of their actions instead of "taking
it for granted".

At least you have a physical keypad to give you some sense of
tactile feedback.  You *know* you pressed the button (imagine
having to look at the screen to see the button *appear*
depressed).

> 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.

I think it was Motogorilla that *used* to code their phones
in assembly language.  Concerned with speed and performance.
Obviously, SmartPhones have thrown all of that by the wayside.

> 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.

And, it depends on how they use/access the Flash.  I.e., do
they fault pages in on demand so the code can at least *partially*
run without having the entire image resident?  Or, does it have
to load the entire image before it can even *start* executing??

>> 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.

No idea.  It depends on how much information hiding goes on in the
system.  I.e., can apps bypass the published API and tweek things
below?

> It
> would also explain why LBE never appeared to be having any effect on
> system performance according my process viewer/manager.

But, if there is a single trap that all calls pass through,
then LBE would have to sit on that trap and inspect *every*
call to the OS to know which it should act on.

OTOH, if there were discrete entry points that could be
individually hooked, then the cost associated with LBE
would only be apparent on those calls that it *wanted*
to filter.

> 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.

See above (?)

> 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.

Understood.  And Android itself doesn't "accommodate" the user's
desire to enforce their own privacy rules.  "Trust the App.  The
App is Good.  Hail, App!"

>   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.

Yes, as I mentioned in my PM.

Can you be sure "uninstalling" an app actually removes all vestiges
of it?