Asus must have went to different memory in the N7. My N7 scores below
My TF700 scores
Yes, because it is a nexus device, all source code is available and there is zero skinning to have to work through. Devs are now having the Android equivalent of drag races to see who can make the cpu/gpu scream the loudest...well you get my drift. I got a Nexus 7 pretty early on, and believe me, it was nothing too impressive until motley and team eos and the others started getting revved up.
OK, OK, we've got it...our $600 device has crappy hardware that makes it have poor benchmark performance and nothing we can do will make it better...we will always be "robbing Peter to pay Paul" so are you happy now? I'm really going to stop participating in this absolutely fruitless game and go back to enjoying my fabulous Infinity TF700 tablet and keyboard dock. I'll watch my movies, browse and read and write and listen to music to my heart's content. Enjoy your Sunday....over and out!Thanks. Kind of what I suspected. Top left is your (best) score, top right is BxMxK's that he posted a couple of pages back. He said he tweaked some settings that improved his scores. The improved Quadrant scores on Zeus are based on the faster SQL time. What's happening though is you're robbing Peter to pay Paul. The SQL numbers improve dramatically but at the expense of reads, especially sequential. The macro performance (browser, market, camera, and camcorder) also suffer. Like Vellemo, Quadrant's IO component is four simple tests - file and database reads/writes. Zeus' tweaking of SQL is what's causing the database scores to improve in Quadrant (half the test) and the scores to show the improvement they do. But if you run IO-specific benchmarks like AndroBench and RL Benchmark you'll see that the better SQL performance comes at the expense of other IO functions. In other words, the pie isn't getting bigger the sizes of the slices are being shifted. So while the tweaks are good for benchmarks actual day-to-day performance will suffer because of the pretty significant drops in read speed which is more often used. For comparison, the screen shot on the bottom left is a JB TF300 and a Note on the right.
Bottom line is that without a dedicated IO controller there's only so many functions that can be performed concurrently. That also explains the universally poor write results. All Zeus and BxMxK's tweaks are doing is giving higher priority to the SQL calls at the expense of others. The biggest issue that Anand confirmed in his testing can't be overcome with s/w. And that is concurrent processes overwhelming the NAND solution Asus is using and turning what should normally be sequential (faster) processes in to random (slower) ones. He posted a video demonstrating this where a background download destabilizes the browser. People will see different results based on the apps they use, the background syncs they have going, and whether or not they’re doing IO related things at the same time. That explains why some people notice IO related issues and others don't. One other thing to note. With JB Google is introducing much more multithreading support including in the OS itself. As more apps are rewritten to take advantage of this more concurrent processes will be introduced. That’s not a good thing based on Asus’ NAND implementation and may be one of the reasons they moved off of it for the N7. So that's pretty much the state of the union.
