#Severe UI Lag After Shorebird Patch Due to SignalR Handling on Main Thread

1 messages · Page 1 of 1 (latest)

azure cove
#

We’re receiving a large payload through SignalR, and it was initially being handled on the main thread.
While the app store version runs smoothly, the app starts to lag heavily—sometimes freezing the UI—only after applying a Shorebird patch, even though no changes were made to the relevant code.

We’ve decided to offload the SignalR processing to an isolate as a workaround, but it’s concerning that only the patched app is affected despite no direct modifications in that area.

Have you encountered similar behavior or know why Shorebird patches might introduce this kind of performance issue?

#

@median briar

median briar
#

Can you share the app id?

azure cove
#

Parsing the data and rendering it on the screen is causing significant performance overhead.

#

okay just a second

median briar
#

Yeah. Sounds like a low link percentage. Sounds like some of the parsing code ended up on the interpreter unexpectedly.

azure cove
#

While we’re waiting for the app ID, I just wanted to share that we’re currently running a live tournament and actively using Shorebird. It’s been really helpful so far, and we appreciate it a lot.
That said, we’ve been seeing more issues on iPhone than expected, which is a bit unfortunate.

#

fd69bce0-dc13-4a90-b534-ab216b44b57a

#

157+937
Patch 5

#

Android is perfect so far

median briar
#

Looking now.

#

Yeah, Shorebird is amazing and magical until you hit this iOS limitation 🙁

#

It's definitely frustrating when it appears, checking now to see.

# 
{
 "release_platform": "ios",
 "used_ignore_asset_changes_flag": false,
 "has_asset_changes": false,
 "used_ignore_native_changes_flag": true,
 "has_native_changes": false,
 "inferred_release_version": false,
 "link_percentage": 94.26709815365946,
 "link_metadata": {
  "link_percentage": 94.26709815365946,
  "reasons": [
   {
    "reason": "Object Pool Load",
    "count": 615,
    "percent_impact": 4.200937617382762
   },
   {
    "reason": "Dispatch Table Call",
    "count": 237,
    "percent_impact": 0.7035019792539513
   },
   {
    "reason": "New Code",
    "count": 79,
    "percent_impact": 0.6672614059926608
   },
   {
    "reason": "Unknown",
    "count": 27,
    "percent_impact": 0.12748129099367217
   },
   {
    "reason": "Load Static Field Address",
    "count": 1,
    "percent_impact": 0.033603975844433524
   }
  ]
 },
 "environment": {
  "flutter_revision": "fb8d194ceb0794310387baff34d657edad7219b8",
  "shorebird_version": "1.6.39",
  "operating_system": "macos",
  "operating_system_version": "Version 15.5 (Build 24F74)",
  "shorebird_yaml": {
   "app_id": "fd69bce0-dc13-4a90-b534-ab216b44b57a",
   "flavors": {
    "app_prod": "fd69bce0-dc13-4a90-b534-ab216b44b57a",
    "app_stage": "70b9666d-dcea-4871-b129-cfbce9ade020",
    "app_test": "9d188101-5cd2-4f84-8547-6fabb698fbd2"
   },
   "base_url": null,
   "auto_update": false
  },
  "xcode_version": "Xcode 16.3 Build version 16E140"
 }
}
#

That's the metadata we have on that patch.

#

94% is lower than expected, but not bad.

#

So yeah, that's pretty recent. We did just make more improvements to linking, including specifically object-pool linking, in our latest 3.32.0 and later releases.

#

My guess is that this is just "bad luck"

#

I'm happy to investigate more if you're able to share the patch-debug.zip (codemagic saves it for you if you're using CM)

#

But my guess is that the problem is that 6% of code which its running on the interpreter, is unfortunately important to that screen.

#

The interpreter is about 100x slower than the CPU.

#

But yes "While the app store version runs smoothly, the app starts to lag heavily—sometimes freezing the UI—only after applying a Shorebird patch, even though no changes were made to the relevant code." is exactly the behavior here. 🙁 @fresh iris and I continue to work on improving this.

#

Good luck with the tournament.

#

You can always revert the patch on iOS if you like.

#

94% is generally good enough that our tooling will not warn

#

Although you can set that warning limit yourself if you like.

#

I think the flag is --min-link-percent, but I'd have to look.

#

I should document it on that page.

#

--min-link-percentage The minimum link percentage (0-100) required in order to generate a patch (Apple platforms only).

#

I wish I had a better answer for you.

#

In this case, somehow the constant pool got jumbled (again we just made another fix there yesterday, but that only appears in 3.32.0 or later flutter)

#

the "object pool" is the "contstant pool" and it's the big List<Object> that the Dart compiler uses under the covers to hold all your constant strings, etc.

#

And somehow in this patch it ended up jumbled.

azure cove
#

We’re currently running the WSOP, one of the biggest poker tournaments, with live coverage planned for between 60,000 to 100,000 users throughout the event.

Every time we release a hotfix patch, we need to push an update immediately, and I’ve been actively recommending Shorebird for this purpose.
But with this issue, it’s making us question whether we can rely on it in critical production environments.

That said, we really want to keep using Shorebird as our go-to tool for future tournaments—we run multiple large-scale events like this every year.
We truly appreciate your continued support and hope to build a strong and dependable partnership going forward.

#

I’ll share the details you provided with our app team.

Would it be possible to confirm whether upgrading to a newer version would improve this issue, or if it’s something that could be addressed in an upcoming patch?

median briar
#

Your concerns are valid. We continue to make improvements on iOS to reduce the chance of unrelated-performance changes like this happening after patching.

#

The only mitigation I can offer at present would be to always pass something like --min-link-percentage=99 during patching on iOS. That woudl cause the patch to fail if we fail to share at least 99% of all code between the patch and the release.

azure cove
median briar
#

(Not that it makes anything better, but as you've seen this is an iOS-only issue.)

#

Felix and I have more improvements planned for next week. The difficulty with this issue is the "randomness" of it.

azure cove
#

So those randomness means
If I do another patch
Then the code that now we’ve got problem with might not affect too?

median briar
#

It's not randomness in the sense of "if you patch exactly the same code again you'll get different outcomes", but it is "random" in the sense of "it's very hard to predict if a given code change would be affected by these non-local compiler changes". https://docs.shorebird.dev/code-push/performance/ discusses further.

Shorebird
Patch Performance

Information on Patch Performance

#

You didn't do anything wrong. We've just not refined this part of the system enough so you never see this.

#

In this case, you got what we would consider a good linking result, but clearly the 6% of code we were not able to run on the CPU was performance critical.

#

You likely changed < 0.01% of your app by total volume of source code (including flutter, dart libraries, etc.). The fact that it showed up as a 6% change is the bug we're continuing to try and address.

azure cove
#

Thank you so much for checking everything so quickly and responding with such care and sincerity — I really appreciate it.

On a separate note, based on our experience using Shorebird this year, I’m planning to give a talk at DevFest Korea 2025.
I hope to share our journey and encourage more developers to adopt Shorebird through the presentation.

Thanks again!