The Android Lag Fix That Really Wasn't 226
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
How important is "true" randomness, anyway? (Score:5, Funny)
Re:How important is "true" randomness, anyway? (Score:5, Funny)
No, they should return 4 - it's guaranteed to be random [xkcd.com].
Re: (Score:3)
Re: (Score:2)
Intel's Digital Random Number Generator has a Dilbert mode (not available to mortals) in which it only outputs 9.
I had to choose between xkcd mode and Dilbert mode. Dilbert mode won.
Re:How important is "true" randomness, anyway? (Score:5, Interesting)
If the problem is that they can't generate "random" number fast enough, maybe they could just return 42 when the entropy pool is empty.
It depends on what you are doing with that entropy. Cryptographic applications, probably best not to mess with. Mathematical simulation work? Please consult your handy local PHd, spawning little spaceships in your arcade game clone? Probably not an issue.
Because it's really application dependent, Linux has two ways of asking the kernel for entropy: Reading /dev/random will pull from the kernel entropy pool and block if the pool is empty. How fast the pool refills depends on the hardware platform, presence/absence of dedicated cryptographic hardware, interrupts and network activity, etc. Reading /dev/urandom will never block; but the results may be unsatisfactorily random if the entropy pool is low.
In either case, applications are also free to use material from /dev/random or /dev/urandom to seed their own PRNGs.
Re:How important is "true" randomness, anyway? (Score:5, Funny)
Re: (Score:2)
>In either case, applications are also free to use material from /dev/random or /dev/urandom to seed their own PRNGs.
Just because they can, it doesn't mean they should.
Mac OS X /dev/random (Score:2)
Uses AES. You can perturb it by writing "entropy" to the device to reseed it, but obvious it never runs out like the Linux /dev/random.
Re:How important is "true" randomness, anyway? (Score:4, Funny)
You mean that the placebo effect still works? (Score:5, Informative)
This is why "vortex" generators for carburetors are still sold http://www.vorteccyclone.com/ [vorteccyclone.com] , Magnets for your fuel lines to "align the molecules" http://en.wikipedia.org/wiki/Fuel_saving_device [wikipedia.org] are still sold, and oddly shaped bicycle cranks http://z-torque.com/ [z-torque.com] are still sold. Its really no surprise that it happens in the software world too. Really, its been happening for a long time. Regcure, anyone?
Re:You mean that the placebo effect still works? (Score:5, Insightful)
The surprising thing, in both this Android case and the assorted car-widgets, is not that the placebo effect works; but that the "If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.
In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?
In the Android case, it's not like entropy related issues are news to linux users or hardware makers. Devices that do lots of crypto(ie. network gear designed to support a lot of VPN users, http load balancers designed to serve a lot of SSL sessions, etc.) are frequently provided with dedicated hardware RNGs precisely to prevent performance issues on entropy depletion. VIA's more recent CPUs come with an on-die hardware RNG, and you can buy assorted RNGs for various expansion busses if your applications require it.
The issue isn't so much that you can entropy-starve a system and cause it to respond badly; but that(against a background of people already knowing that) Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.
Re: (Score:2)
In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?
Because Company/Lobby X paid them $$$ NOT to include thingamajig that would save you money by not buying the product X or by buying less of it - making less money for the Company X.
It's all a part of the plan. [wikipedia.org]
Re: (Score:2)
Don't ever write one yourself (Score:3)
Bad crypto can cause you no end of trouble. There are people out there who know what they're doing who've written PRNG systems in the general direction that you're talking about, but understand what to do and not do in the designs. Some of it's pretty subtle, like only bringing in new entropy in big chunks rather than trickling it in, and knowing what crypto algorithms work well for applications like this and what don't. And some of it's tuning.
Go read the "/dev/urandom" Wikipedia page. [wikipedia.org] If you need Yarr
Re: (Score:2)
This is good reading. There is good reason why people don't invent the wheel with cryptographic protocols.
Maybe it is time for a patch to the Linux kernel to make /dev/urandom non-blocking as well?
Re: (Score:3)
I've never heard of DoubleRAM, so it can't be that big. The biggest software scam has to be anti-virus.
Re: (Score:2)
I've never heard of DoubleRAM, so it can't be that big. The biggest software scam has to be anti-virus.
It was called "RAM Doubler" - A-V is probably the longest lasting scam. but RAM Doubler burned very bright for a couple of years.
Hey, RAMdoubler worked for Johnny Mnemonic (Score:2)
Ok, it only works if you've got a cybernetic dolphin who can use SQUIDs to read you brain, but you could still become a very technical boy...
Re: (Score:2)
RAMDoubler created a compressed swap partition. It actually worked as advertised, depending on your setup it may actually make things faster for you, but buying more ram was ALWAYS the proper solution.
VMware stores duplicate memory pages between OSes in a single instance across multiple running VMs. This is no different than what Linux, BSD, or Windows do with things like EXE backing stores already except VMware has to search out duplicate pages as it doesn't really know how the underlying OS does its thi
Re: (Score:2)
I think you mean "RAMDoubler" which supposedly compressed your virtual memory, but did so ineffectively.
However VMWare currently advertises a similar feature.
No, RAMDoubler at least had some effect, the scam was SoftRAM [wikipedia.org]
Re: (Score:2)
I think you mean "RAMDoubler" which supposedly compressed your virtual memory, but did so ineffectively.
my recollection is that it patched the Toolbox Memory Manager with a proper virtual memory system - giving OS9 shared pages, efficient swapping and some compression on the pages. It was done by the same folks who did the PC emulator and the various mags of the day saw very positive benchmark results ... why does everybody here seem to regard it as snake oil?
First Post (Score:5, Funny)
but sent using Android, so...
article doesn't make sense. (Score:5, Interesting)
Re: (Score:2)
The butter project was about latency with user interaction. The issues talks about /dev/random, which is totally unrelated.
Well, you'd hope it was unrelated, but sometimes I'm no so sure ;-)
Re: (Score:3)
Look at the first sentence of the linked page: The Linux entropy pool is frequently empty as Dalvik appears to always use /dev/random, which depletes the entropy pool and will block when the pool is empty. This blocking results in user perceived poor performance.
Re: (Score:2)
I was under the impression that the fix did actually speed it up, but at the cost of battery life. You could have got effectively the same performance enhancement by changing the process scheduler to 'performance' rather than 'on demand'. As someone with an older phone running Cyanogen, I was hoping this fixed helped. My performance problems tend to be more memory related though as the older phones are quite short on RAM.
Re: (Score:2)
Which "fix"? There have been many proposed. The only ones with a measurable effect have been ones which caused battery issues. What these did were renew the entropy pool quite frequently and as a result the CPU never went to sleep. The effect it had was changing the CPU governor to always keep the device awake. No wonder that improved performance.
This entire debatable has been nothing but one great placebo, and really at this point I think it actually reflects quite poorly on the XDA community who are full
Re: (Score:3)
Look at the first sentence of the linked page: The Linux entropy pool is frequently empty as Dalvik appears to always use /dev/random, which depletes the entropy pool and will block when the pool is empty. This blocking results in user perceived poor performance.
The problem is that XDA-Developers seem to have attracted a lot of script kiddies who've done Java / C / Programming 101 and think that they know everything. Despite endless threads about this Google's own developers have come out said that Dalvik does not use /dev/random for anything.
Better still none of the proposed fixes had any measurable improvement in performance except for one which quickly drained the battery (and likely kept the CPU awake at all times and running at full speed).
Re: (Score:3)
Of course, it was actually just an old android bug that'd been fixed ages ago, iirc.
the placebo effect (Score:2)
Apparently, the placebo effect also works to cure percieved computer ailments...
Re: (Score:2)
I don't get it. There were no numbers posted in the thread. This doesn't mean placebo, this just means there are no numbers posted. The claim that it's placebo has just as much foundation that it's not. Write a benchmark and test it, you could get exactly 2 minutes of fame.
Beware of more of this stuff on XDA (Score:5, Insightful)
Re:Beware of more of this stuff on XDA (Score:5, Informative)
yep, the place is cargo cult central. stick with builds of the major ROMs from affiliated devs, is my advice. Run like hell from the threads which are kangs of those builds with some kid's AWESOME BLACK THEME and a bunch of kernel patches he picked up somewhere.
Re: (Score:3, Insightful)
The funny thing is those dweebs spill out onto the general internet and tell everyone they need to hack their phones.
Then you read a 45 page thread only to find that their wicked sweet ROMz don't support the camera and give the phone 30 minutes battery life. Gee thanks, Melvin.
Just finished reading the whole thread (Score:4, Interesting)
There are a lot of comments on the bug report page. Clearly this is not a dalvik bug since dalvik does not use the /dev/random. But the other commentatros are still unsure that there might not be some issue in how randomness is generated in android from user input, which might induce lag.
Right now, some folks still investigate.
Well yeah... (Score:2, Insightful)
Because you can't fix stupid.
Jury is still out (Score:2)
>> "didn't actually speed Android up."
If you actually read the bug mentioned in the summary - most devs are arguing that explanations about why the fixes work don't make sense in terms of Dalvik (java) that the android bug was filed against - not that it doesn't improve latency or that it doesn't work or there isn't a lower level issue. One developer https://code.google.com/p/android/issues/detail?id=42265#c162 [google.com] (sorry I don't know enough about android to know if he is part of the core team or not)
Looks like a real bug to me (Score:2)
This looks like a real bug to me. /dev/random instead of /dev/urandom, which of course causes them to be unnecessarily slow.
The problem is that many apps use
A "hack" was to make /dev/random behave like /dev/urandom, but it's not clean, which is why it's not done in the official version.
The jury seems still out on this (Score:4, Interesting)
Having slogged through the linked discussion, there is no conclusion either way whether this effect is real or not. There are several theories on mechanisms that could cause an increase in responsiveness, but no conclusion. The most plausible seems to be that when the entropy pool is near empty, each input event causes a context switch as it is used to refill the entropy pool. Slower input handling obviously leads to poor responsiveness.
The summary seems to just be random android-bashing.
Its like a train wreck... (Score:3)
Reading that bug report makes me incredibly glad that I've only worked on open source developer tools, if the comments on that bug report are typical I imagine Google must have high turn-over of developers on the project.
Did you even read the thread you linked to? (Score:5, Informative)
Re: (Score:2, Flamebait)
Speaking from personal experience I own an Ipad 2 and a Nexus 4, the UI in the iPad 2 is smooth as silk as usual, the UI in the Nexus 4 is even better in terms of speed and responsiveness. Switching between applications is seamless and the UI will not drop a single frame.
The user experience in Android was lacking until Matias Duarte took over the UI, in modern phones it's as good if not better than anything on the market, period.
There are four things that make Android laggy (Score:5, Interesting)
There are basically four things that make Android laggy. The good news is that most of them can be overcome by user-modified firmware. The bad news is that manufacturers and Google are unlikely to ever fix them directly, because it would increase the manufacturing cost of phones by a few cents.
ONE: KILL-VS-SWAP
Android's normal behaviour is to aggressively kill activities and suspended background tasks, then respawn them from scratch when brought back into the foreground or reactivated. The LINUX (and Windows) norm is to simply quit giving them CPU cycles, stash their state into swap space on the hard drive, and resurrect them later.
One reason why this is done is because Android devices, while not necessarily STARVING for flash, don't have it in quite the abundance that a normal computer has hard drive space. There are also concerns about prematurely wearing out flash. The problem is that flash rewrite life estimates are based upon general use of the entire block of memory... but a swap partition gets created in a specific chunk of flash, and that one tiny chunk gets relentlessly hammered. If your erase-rewrite activity gets spread across the whole flash, it would usually take months of active efforts to be destructive before you really caused damage. However, if you create a 256mb swap partition and hammer it relentlessly, you can permanently damage it in a weekend. For this reason, few at XDA will advocate ever using internal flash for swap.
That brings up catch #2... if you swap to microSD (because it's cheaply replaceable should you end up damaging it), you really need class 6 or better. Swapping to class 2 flash will leave you running more slowly than if you left Android to its default behavior. Guess what class of flash invariably comes with the free microSD card shipped with the phone? Class 2.
Making matters worse, the users in the best position to experiment with swap enhancements are Nexus owners. Unfortunately, Google has this near-religious aversion to microSD, and I don't think any Nexus device since the original Nexus One has shipped with a microSD slot. All that said, if you have a rooted and reflashed Android phone with class 6-10 microSD that has a swap partition and a custom ROM that uses it, you MIGHT see a big reduction in lag if you frequently run apps that have "expensive" startup costs (ie, apps that always begin by trying to make a http request to somewhere, or generate cryptographically-secure random numbers, etc).
TWO: DISDAIN FOR 2D GPU ACCELERATION
Historically, Android hasn't done a good job of putting 2D acceleration to good use ICS was a step forward, but you can't help but feel like the GPU support is more symbolic, half-assed, and buried under 400 abstraction layers that fritter away most of its potential. At least, for simple and straightforward "scroll and/or pan the viewport across a large virtual bitmap" type operations.
Compounding the problem is Android's architectural bias towards generating content on the fly, instead of generating humongous virtual bitmaps and keeping them available for instant viewport rendering.
THREE: ANDROID'S MEMORY-MANAGEMENT SUCKS
Building upon 2, and being completely blunt... Dalvik's memory-management totally fucking sucks compared to Java's. ESPECIALLY the way it handles short-lived objects that get repeatedly created in large numbers, and discarded almost immediately.
I dare anyone to disagree. Half the Android API bends over backwards to tiptoe around Android's shitty heap-management by trying to avoid creating and discarding objects for use as short-lived containers.
No, don't give me crap about mobile devices having limited resources compared to desktop computers. That's bullshit, and everyone knows it. Java mostly solved the worst of its memory-management problems around 1.5. Compare the specs of a high-end laptop circa ~2002 with the specs of a Galaxy S3, and arguments about Android devices being "severely resource limited" just kind of fall on the ground and thrash aroun
Re:There are four things that make Android laggy (Score:5, Interesting)
This is a common misconception. The class of the SD card is a rating for sequential write speed, nothing more. It's important for cameras and camcorders - in fact it was developed for camcorders because some memory cards simply couldn't write the video data as quickly as the device was sending it to the card.
For an Android device you're more interested in its 4k random read/write performance. It's basically a computer reading/writing lots of small files, so it'll be most impacted by 4k read/write speeds.
As it turns out, manufacturers can tune a flash card for a certain type of performance. If you tune it for faster sequential speeds, random speeds suffer. Likewise if you tune it for random speed, sequential speeds suffer. The class 10 cards I've benchmarked typically hit 10-20 MB/s on sequential writes, but will bog down to as slow as 0.004 MB/s on random writes (yes, 4 kB/s - it was the card I bought before I learned all this. It took 4 hours to copy 4 GB of sheet music and MP3s to that class 10 card - a blissful 0.28 MB/s). Here are the CrystalDiskMark scores I got for a 32 GB class 4 card I have:
seq: 22.9 MB/s read, 4.3 MB/s write
512k: 22.0 MB/s read, 1.3 MB/s write
4k: 3.3 MB/s read, 1.3 MB/s write
Yikes! Only 4.3 MB/s write speed. Who would ever want that? Well look at the benchmarks for a 16 GB class 10 card I have:
seq: 21.8 MB/s read, 12.0 MB/s write
512k: 21.5 MB/s read, 0.9 MB/s write
4k: 5.7 MB/s read, 0.008 MB/s write (not a typo)
So yeah it's 3x faster at sequential writes. But it's slower at 512k writes, and more than 160x slower at 4k writes. It's definitely a very bad choice for an Android device despite being class 10.
The sweet spot for Android is around class 4 or 6. That gets you good 4k write speeds without punishingly poor sequential write speeds (which are important if you're doing something like copying a movie to the card). That said, not all cards are created equal. The "class 2" Samsung card which came with my phone is hands down the best card I've tested overall. It peaked at 11 MB/s sequential writes (meaning it could've been rated class 10), while 4k random writes were still above 1 MB/s. Sandisk is another company which seems to underrate their cards (and their class 10 cards have better if not stellar 4k random write speeds), which is why they're usually highly recommended for Android devices.
tl;dr - You want a class 4 or 6 card, or a good class 2 card for your Android device. Not a class 10 card.
Re: (Score:2)
you reach a concluding advice while ignoring the very thing you yourself said: class is for seq writes.
which means that if you write many small things in your card, you need a class 4. However, what if you need your card to write large files?
of my 32GB card in my arc, 28GB are FLAC and the rest is mostly empty (perhaps 10 photographs at most, far *far* less than even 1GB)
so your idea of using a class 4 (which i did, the 32GB it came with was class 4) would be torture for me when i update its library.
think a
Re: (Score:3)
There are lots of other issues. Two examples:
A) The Dalvik JIT is stone-age technology compared to modern JITs. We are not even talking about profile-guided optimization like the HotSpot VM does. No, it does not even inline getters or setters,
B) The GPU acceleration layer sucks even worse than you think. For example it requires the app to emit display lists for all graphical objects without allowing you to clip those objects first. That means if you have a huge number of objects (say an editor with thousand
Re: (Score:2)
So when I click to dial someone on my DroidX, and I can fast count to 20 before the phone connection screen even launches, which of the four problems above do you think it is? I'll experiment with your solutions (does CyanogenMod help?), but I'm curious what you think the main culprit is with something as simple as calling - or worse, answering - using the default phone app.
Re: (Score:2)
FOUR: ANDROID'S DEFAULT CPU GOVERNORS MAKE AN ANNOYING PROBLEM INTOLERABLE
This is very interesting, as almost all desktop computers use ondemand too. My old CPU was a Phenom II quad core at 3400 MHz and it was noticeably slower on "ondemand" for interactive stuff. I ended up writing a script to pin it at performance, and switch to ondemand when the screen saver was on. Now I'm using a Xeon and I haven't noticed any difference. The Xeon only clocks down to 1600 MHz, while the AMD went all the way down to 800 MHz.
I wonder why the "interactive" governor isn't available on my desktop
Re: (Score:2)
> Android does save Activity state, it's lifecycle 101. Just look at the onCreate method signature. What do you think "savedInstanceState" means?
Yes, it does save its state. But after roughly 30 minutes, Android will become increasingly determined to kill it off at the slightest pretense and first possible opportunity. It's kind of like Windows and virtual memory... you can have 16 gigs, with 13 free, and Windows will STILL swap stuff out to virtual memory. Likewise, you can have plenty of free ram on y
Yeah, I have noticed some lag. (Score:2)
I have a G2. Not rooted or anything. Most of the time it's fine. Every so often, when I touch keypad buttons during a call, Nothiing Happens. A few seconds later, any and all buttons I've hit will play back very very fast.
It really is quite noticeable.
no lag on Galaxy Note 2 (Score:2)
Re:Does it matter? (Score:4, Interesting)
My Google Nexus tablet begs to differ with your assessment.
Re: (Score:2)
And? My google nexus tablet begs to differ with your assessment, you insensitive clod!
no really - mine runs quite smooth, even if battery life went to crap after the latest patch.
Re: (Score:2)
Links coming up in Chrome from external apps are slow as heck. Once Chrome starts it's fine, but it just sits there. *Tap* 5-6 seconds, then Chrome.
Haven't noticed anything about battery life, although I had previously disabled Currents, which is the supposed cause.
Re: (Score:3, Interesting)
This might be related to chrome.
Maybe you want to try firefox for android - it works quite well for me. If it turns out to be faster, it's still google's fault, but then you know the chrome guys are responsible, and not the android guys...
Re: (Score:2)
I find opera the fastest but I miss my desktop sync
Re:Does it matter? (Score:5, Interesting)
I've only been using Android since 2011 and my devices have never had any kind of lag. Maybe because I have Nexus devices that aren't encumbered by third party skins and interfaces.
Re: (Score:2)
All touch devices have lag, including iOS, and it's significant. Anyone that's tried to draw using these devices knows this. Check this out: http://www.engadget.com/2012/03/10/microsoft-cuts-touchscreen-lag-to-1ms/ [engadget.com]
Re: (Score:2)
Re: (Score:2)
Lazy Googling on my part -- I just pasted the first link to the thing I found. I think I originally can across this in a podcast.
Re:Does it matter? (Score:5, Interesting)
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
Its not actual lag so much as poor UI choices that are perceived as lag at this point in my opinion, but I most certainly can 'feel' the lag.
Re:Does it matter? (Score:5, Interesting)
We're currently finishing up a fairly simple music app for Android with a couple of fun features.
In the beginning we were fussing around a lot with the Android UI and Audio APIs, as the lag when a user pressed a button widget until audio was played was very noticeable, we couldn't get rid of it. After hitting a brick wall we simply started from scratch using only a blank canvas, manually drawing buttons and handling events and the like and things worked perfectly.
So I the lag we (and probably everyone else) experiences has little to do with Dalvik but everything to do with the Android UI widget event handling, it causes unresponsive UIs.
I never noticed it before but now I see it all over the place. The only apps that don't have it are games and apps like ours who sidestep most of the Android Widget/Event API and go the manual route.
Re:Does it matter? (Score:5, Interesting)
It seems like on Android, the less you rely on built-in libraries/APIs the better your app will be.
Which is the opposite of how things tend to go with iOS development.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
how do you manage the audio glitches when the garbage collector is run?
It's incredible. An ARM running at 1.6GHz with half a gig of mem and it can't play an mp3 without glitches.
Re: (Score:3)
Or you just don't notice it.
I find that anyone used to an iOS device can pick up a Nexus 7 and notice the lag.
If all you use is Android devices, you probably don't notice.
I found the opposite.
I only used Android up until work made me carry an Iphone 1 week out of every 4. Found that IOS was so slow compared to Android 2.3 (Gingerbread) but they just covered it up by using animations. It too longer to open the messaging application on IOS than on Android.
I timed them side by side, Android was much faster to open the application. The phones in question were an Iphone 3GS and a Motorola Milestone (Moto Droid) so they had fairly similar specs. This was on IOS version 3, wh
Re:Does it matter? (Score:4, Informative)
Possibly. I never had a 'nexus', just the basic Samsung stuff. One problem that I noticed is when running 'drum kit' apps. I have tried some on my Android phone and several on my iPad (1st generation). On the iPad the drums react almost instantaneously. On the androids there's a noticable (and fatal) delay.
Did you ever try anything like that on you nexuses?
Re: (Score:2, Insightful)
If you've used an apple device then an android device, you realize how slow android is. It's not terrible, but it greatly diminishes the user experience because the screen isn't glued to your finger.
Re: (Score:2, Interesting)
Bullshit fanboy.
Even the Nexus 7 lags. I'll buy that you don't' notice it, but it most certainly does. I've had and returned two Nexus 7s hoping to find the lag had been fixed, but it hasn't.
Part of the issue is the way apps are written rather than the OS at this point I think. The play store is a prime example of visible lag that exists due to a poor app design.
Scroll through the play store on a nexus 7 device quickly and it'll scroll fine then stop cold in its tracks, which a sliver at the bottom of th
Comment removed (Score:5, Insightful)
Re:Does it matter? (Score:5, Interesting)
The time between clicking an app and it appearing on your screen is not lag. That is just the OS being a little slow. Lag is scrolling on the screen and having the graphics catch up with your finger. It's there and it has been perceptible on every Android phone I have used.
Re: (Score:2)
Probably because the mods read the entire post in context.
Re: (Score:2)
I'm going to be honest, but I'll probably be modded into oblivion, and/or called a shill.
I bought a Nexus 7 because I wanted a tablet, I didn't want to spend $329 on an iPad mini, and Jelly Bean was supposed to fix the lag issues. I wound up returning it for a variety of reasons, but one of them was that the UI performance felt about on-par with a first-generation iPad (which I also sold, though for different reasons). I really wanted to like it. For all I know as someone who doesn't use Android, Jelly B
Re: (Score:2)
Its UI performance and subjective responsiveness are still not on the level of iOS as iOS was 3 years ago.
My old iPhone 3G is more touch-responsive than my Galaxy Note.
Re: (Score:3)
I believe I stated modern. I would have no problem to tell you if my Nexus 7 or HOX lag, but they don't... I'm sure you can dig up a case where they lag, but normaly, they are fluid.
Re:Does it matter? (Score:5, Interesting)
I can only speak for the Galaxy Tab 2 7.0, but modern Android devices are faster in part because of software performance improvements. Android 4.1 and 4.2 both have performance improvements, and upgrading the Tab 2 from the 4.0 it came with to 4.1 or 4.2 makes the OS visibly faster. The Nexus 7 comes with Jelly Bean (can't recall if 4.1 or 4.2 out of the box), so everything is fast to begin with.
In this way, Android is similar to Mac OS X - initial releases were rather slow, and subsequent versions (10.1, 10.2, maybe 10.3) were faster simply because there was a lot of easy optimization work to be done.
As an iOS user I didn't really like Android until Jelly Bean.
Re:Does it matter? (Score:5, Interesting)
but modern Android devices are faster in part because of software performance improvements.
Historically you can always get more performance improvements out of software than hardware. Software improvements of 100x on bottlenecks are not uncommon (Google for example has made a ton of them in search, http, maps, etc). This is the same as running on hardware that is five or six generations in the future.
The classic quote is that primality testing has benefited more from better algorithms than from 40 years of Moore's law.
Re:Does it matter? (Score:5, Interesting)
I like to try drum kit apps ( I have kids ). But on my Android phone there's a perceivable (and intolerable) lag when you tap the drums with all the apps I tried. On iOS (1st gen iPad) they're all nearly instantaneous.
Ever try anything like that?
Don't get me wrong, I'm not an Apple fan, I'd like Android to win, but not by closing my eyes for its faults.
Re: (Score:2)
Re: (Score:2)
I am using G-stomper, sometimes on a SGS1 with Gingerbread, all bells and whistles enabled, and I have rarely seen lags, except when Tasker fires something in the background.
Haven't used any other drum kits or machines, so can't really comment on those, but if one can get it right ...
Re:Does it matter? (Score:4, Insightful)
Can I root for no one to win, but for it to remain a stalemate with several competitors?
Or do we all need to wave the flag for one uncaring corporate juggernaut or another?
(Also, do we have to present credentials like this with every opinion we post? Would the validity of your opinion change if you were an Apple fan? Are we reddit?)
Re:Does it matter? (Score:5, Insightful)
I have nothing against Apple perse, but I have serious issues with the closed nature of their iOS devices and especially how I don't have the ability to control what gets transfered on or off the device. Everything has to go through iTunes or some cloud solution.
Android has no such restricting policies, that's why I'd like to see it 'win'.
Re: (Score:2)
Re:Does it matter? (Score:5, Insightful)
You can't have 0 latency audio drivers. But the latency can vary from system to system due to design decisions.
The main source of latency in audio drivers is related on how many audio samples are generated for each call to the interrupt handler (buffer size).
Bigger buffer sizes help avoid gaps in audio due to interrupt jitter. They also reduce the CPU load and energy usage which are very important in mobile devices.
Driver infrastructer for very small buffer sizes need to be designed very carfully to work reliably. So there are many reasons why android developers decided not
to use very small buffer. BUT of course for any kind of interactive audio low latency is crucial.
Re: (Score:2)
Linux can provide realtime (guaranteed latency - zero latency doens't exist on a Von Neumann machine) services (hard realtime even with a proper microkernel) but the issues Android has aren't general to linux driver latency, they're special Android issues.
And boy would I like to see them get cleaned up! Google must have profilers...
Re: (Score:2)
They have to address all the trolls.
Otherwise they look like they don't give a damn about the end user. Most companies in a free market have to wory about that sort of thing. (pissing off customers)
Re:Open Source (Score:5, Informative)
Here you go: http://download.cyanogenmod.org/?type=nightly [cyanogenmod.org] .
Re: (Score:2, Insightful)
Re: (Score:2, Insightful)
since when does having a non mainline spin off count as being "open to user additions"?
There's no requirement for an open source project to be open to "user additions".
When was the last time you added something to the Linux kernel? Maybe you did, but that process is tightly controlled by the kernel maintainers.
Same thing for Firefox.
You are free to fork Android, like CM did, and make your additions there. Or fork CM.
I'm not saying Android couldn't be more open. But it's understandable that Google tries to keep control so they won't get sabotaged by Apple, Microsoft and others.
Re: (Score:2)
Re: (Score:2)
http://www.youtube.com/watch?v=V5E5revikUU [youtube.com]
Re: (Score:3)
Untrue. Modern Java (since 1.6, if not earlier) has nearly native performance on most platforms.
Android's "Java" problems are specific to DalvikVM inferior heap management strategy. Java 1.5 and newer does a VERY good job of dealing with mountains of short-lived objects that get promiscuously created, then discarded almost immediately. DalvikVM falls flat on its face, and ends up stalling to do garbage-collection.
Part of the blame lies with Android's strong (if not overwhelming) architectural preference for
Re: (Score:2)
Pretty much. Neckbeard rage will ensue.
Re:java is shit (Score:4, Insightful)
When a user clicks (touches, slides, speaks, whatever) an object in the interface, the expectation is that the response will be immediate. Leaving aside communications delays, which users largely understand they have to live with, there is nowadays no excuse whatsoever for the device failing to respond instantly, even if only to provide feedback that acknowledges the interaction (for example when it involves an operation that is known to take measurable time such as opening an image file).
But the OS's own processes are regarded as sacrosanct, so the user interface just has to wait until they condescend to allow the user a few of their precious cycles. This happens on all end-user systems running multiple processes (leave IBM mainframes out of this :-) — just look at the time it takes to get a response from the Unity Dash, or the Gnome menu button, or the Windows Start button (or whatever it's called this week), or the Mac menu button...the first time you click it. It sits there loading its menus. Finally it lets you see them. You run your application, and for a short while, another click on the dash/start/menu will get a fairly swift response. Leave it a little longer, and it's been swapped out and takes another age to reload.
Developers, achitects, engineers, and programmers need to grasp the fact that their background processes must take a back seat when the user wants to do something. Their reply, quite naturally, is that their background processes are vital, essential, cannot be delayed or interrupted, etc etc. And quite right, some of them are. But it's their job to see to it that they are written and scheduled in such a way as not to interfere with the interface. Anything else is a design failure.
Re:java is shit (Score:4, Insightful)
You do understand, don't you, that the reason the user interface has to wait isn't because developers think our processes are more important than the users.... but because the user interface DEPENDS ON THOSE PROCESSES TO BE ABLE TO DISPLAY!
Car analogy: You're complaining the the engine management computer insists on doing its fuel map calculations before responding to the throttle.
Re: (Score:2)
Often my interactions on my Android phone take time to give me any response. That is a failure and any app should work diligently to fix it as I am happy to use a diff
Re: (Score:2)
Re: (Score:2)
You have no idea what a mutex is, do you?
Re: (Score:2)
I agree with you. The real issue is that a PC has a much narrower bus to move all of that data around. You can throw all the cores in the world in one box, and something like a modern mainframe will still stomp it because it is so much more massively parallel.