Why Google Pixel lags 10x more than Moto Z

The title is &quot;Why Google Pixel lags 10x more than Moto Z&quot; but the content is just a microbenchmark of fsync() without anything resembling a measurement of UI lag or that the 10x slowdown in fsync() actually means a 10x (or any) increase in said lag.<p>The author&#x27;s previous blogpost (<a href="http:&#x2F;&#x2F;taras.glek.net&#x2F;post&#x2F;Laggy-phones-and-misleading-benchmarks&#x2F;" rel="nofollow">http:&#x2F;&#x2F;taras.glek.net&#x2F;post&#x2F;Laggy-phones-and-misleading-bench...</a>) contends that 4K writes are a good proxy for phone lag, but has no evidence or measurements either, just the author&#x27;s contention.<p>It could all well be true! And it&#x27;s great the author&#x27;s dug up some concrete areas the pixel team could potentially improve at (dumb question: couldn&#x27;t the pixel be updated to use most of these FS tweaks? could an in-use pixel FS be converted to use f2fs?). But I don&#x27;t think the author has done a good job demonstrating an actual relation to UI lag or anything to do with the phone&#x27;s perceived performance.<p>disclaimer: googler, but I do iOS things.

&gt; The key option is nobarrier. This effectively makes fsync() a no-op and explains most of the difference in performance.<p>In other words, because the Moto Z cheats.<p>I suppose it&#x27;s understandable... nobody should ever be blocking GUI animations on fsync, much less two of them in a row, but here we are.

This articles conflates a lot of things but it also has the priorities somewhat wrong.<p>1) fsync cost. Yes, fsyncs are dangerously slow in any Android app. (SQLite for example is a common culprit. Shared Prefs are another). HOWEVER, it&#x27;s possible that flushes cause reads to be queued behind them (either in the kernel or on the device itself) which is even worse because<p>2) Random read cost is super super important. Android mmap&#x27;s literally everything and demand paging is particularly common AND horrendous as a workflow. To add insult to injury, Android does not madvise the byte code or the resources as MADV_RANDOM, so read-ahead (or read-around) kicks in and you end up paging in 16KB-32KB where you only wanted 4KB.<p>Also, history has shown custom flash-based file system on Android to be a world of pain. yaffs, jffs have some pretty atrocious bugs&#x2F;quirks. I&#x27;d much rather see the world unify on common file systems, optimized for flash-like storage, rather than OEMs shipping their own in-house broken file &quot;systems&quot; (I&#x27;m looking at you, Samsung).

This makes very little sense. The author shows a fsync() benchmark comparing an actualy fsync (Pixel on ext4 without nobarrier) with a nobarrier (no-op fsync) alternative. The only thing this benchmark shows is that a no-op is faster than the real thing.

&quot;try to avoid buying devices that will slow down to point of being unusable as NAND wears out (ala Nexus 7, Nexus 6)&quot;<p>Has anyone experienced this issue with their Nexus 6? My phone is more than 2 years old and I have no noticeable slowdown. The pixel might have the slower storage option but it has no effect on usability. From what I have read its UI performance is the best of any Android phone yet.<p>&quot;The Pixels are fast — noticeably faster than Samsung&#x27;s Galaxy S7. On performance alone, these are easily the best Android phones you can buy.&quot; <a href="http:&#x2F;&#x2F;www.theverge.com&#x2F;2016&#x2F;10&#x2F;18&#x2F;13304090&#x2F;google-pixel-phone-review-pixel-xl" rel="nofollow">http:&#x2F;&#x2F;www.theverge.com&#x2F;2016&#x2F;10&#x2F;18&#x2F;13304090&#x2F;google-pixel-pho...</a>

From Tim Murray, performance engineer on Pixel:<p>&gt;that fsync blog post floating around is pretty much bogus. also nobody should use nobarrier, it&#x27;s not safe at all<p><a href="https:&#x2F;&#x2F;twitter.com&#x2F;t_murray&#x2F;status&#x2F;808373275860418560" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;t_murray&#x2F;status&#x2F;808373275860418560</a>

I don&#x27;t think this could be interpreted as a visual lag. fsync() is usually used by databases, not UI libraries. So the title is misleading.<p>My chinese Android phone has a more annoying hardware lag - a delay between touching the screen and touch event processing is over 100 ms. Any drum app is unusable. And if you try to scroll something up and down fast it is easy to see how the content on the screen lags behind finger movements.

Offtopic: I love my old Moto G, but I&#x27;ve been reluctant to buy any new phones from Motorola since its purchase by Lenovo, due to Lenovo&#x27;s history of shipping computers with rootkits and malware. Should I suspect that Motorola phones are compromised, or am I just being unreasonably paranoid?

<i>&quot;They drove development of the filesystem specifically by Twitter&#x2F;FB&#x2F;etc workloads captured from the phone.&quot;</i><p>Why would Twitter or Facebook apps need to write much to persistent storage? They don&#x27;t do so in a browser.

Related: <a href="https:&#x2F;&#x2F;www.flamingspork.com&#x2F;projects&#x2F;libeatmydata&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.flamingspork.com&#x2F;projects&#x2F;libeatmydata&#x2F;</a>

Other comments are querying the relevance of fsync() as a &#x27;lag&#x27; benchmark, but I want to query whether fsync() is even meaningful at multiple calls per second.<p>I know fsync() ensures data gets written to disk, but why does anyone care that it can happen so often? When a device crashes, some data (prior to the sync) may be lost, but do we really need multiple checkpoints per second to ensure only sub-second data loss?<p>I&#x27;d be content with a couple of minutes worth of loss even on my main PC, with its lack of battery backup. To enforce rapid syncs on a phone seems utterly pointless.<p>Keep the syncs for meaningful checkpoints, like buying something in an app or marking a message as sent. Multiple fsync() calls per second are a total waste.

Any real proof that this actually causes user visible issues at all?

I don&#x27;t see the hard link between GUI smoothness and io. You can have perfectly smooth 12000fps rendering and crappy IO, everything will just be &quot;loading...&quot;.

My old 4S runs annoyingly slow. According to the article,the NAND, as it ages will slow down the phone, so will replacing my storage make my iPhone fast again?

The fundamental problem sounds like it&#x27;s that SQLite insists on not running in its own thread. This, coupled with the fact that Linux has no way to issue a true (i.e., non-blocking) write barrier, means that there is no way to implement write barriers in user space.<p>Whereas, if SQLite <i>did</i> issue I&#x2F;O from a separate thread, one could easily implement an &quot;async commit&quot; function which guaranteed consistency and ordering but not necessarily durability (i.e. a write barrier). This would suffice I suspect for 95% of usage in applications: users will probably be OK if their phone loses the last few seconds of user input before an OS crash, so long as everything else is left intact.<p>EDIT: In fact, Postgresql has an option to permit exactly this behavior: <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.6&#x2F;static&#x2F;wal-async-commit.html" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.6&#x2F;static&#x2F;wal-async-commit....</a> This is possible in Postgresql because, unlike SQLite, I&#x2F;O does not run in the client thread.

If f2fs is so superior to ext4 then why doesn&#x27;t its creator, Samsung, use it on their phones?

I hadn&#x27;t heard about f2fs before. Sounds useful even on a notebook with SSD.

I always wondered why my wife&#x27;s Moto X is still buttery smooth after 3 years!! I love that phone. I have a Pixel but she still has her Moto X and it is really great at being smooth, plus the wave to wake and other gestures are really unmatched by the Pixel.<p>Love this write up&#x2F;research! Hopefully it will teach the Pixel team a few things, or maybe they already knew but will now have the ammo to take to Product and change things!!

I suspect it is not the fsync directly that leads to lag. But that when a fsync comes through, Linux stops doing anything else for the duration.

If you&#x27;re calling fsync on your painting thread, you&#x27;re going to have trouble hitting 60FPS no matter what. What a clickbaity post.

So this might be the reason why some mobile devices (like my ASUS TF700T tablet) degrade in performance so badly over time. Interesting.

Is there an Android sample app that show how to do I&#x2F;O properly (off the main thread, and so on)?<p>I know there&#x27;s some kind of system to prevent network I&#x2F;O on the main thread... w... why... I dare to ask the obvious, w-wwhy isn&#x27;t there a warning for simple disk I&#x2F;O too?

I wonder if this is why my Sony Xperia Z5 is so sluggish sometimes, despite having a Snapdragon 810 8-core CPU...

What does it matter?

&gt; ... noatime,nodiratime, ...<p>noatime implies nodiratime. I shrug off when I see newbies copy pasting this to their &#x2F;etc&#x2F;fstab but this is in a mainstream Android device??

Nexus 5X running rooted AOSP 7.1.1<p>&#x2F;storage&#x2F;emulated fuse &#x2F;dev&#x2F;block&#x2F;dm-0 &#x2F;data ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,errors=panic,data=ordered,inode_readahead_blks=8 (no nobarrier mount option)<p>In theory Google should be able to easily change the &#x2F;data ext4 mount option, why didn&#x27;t Google?

Kinda makes me regret getting a Pixel to replace my Moto Z. Except the reception was terrible on the Z. Oh well.<p>How is it that no one has made a worthy successor to the OG Turbo. That was a monster of a phone across the board.