Parsing time too long while using WireTypeAdapterFactory

[Zogesh]

Environment

• Android (Kotlin)
• Wire version: (add your version)
• Gson / Moshi version: (add versions)
• Proto generated using wire-compiler
• App supports both binary protobuf and JSON responses

📌 Summary
I have an Android app that has used protobuf + wire-compiler–generated Kotlin data classes for a long time. Proto decoding is extremely fast, as expected.

We also added an option to return JSON responses for the same proto schema. To support this, I registered WireTypeAdapterFactory with Gson so I can decode JSON into the same generated Wire messages.

However, after switching to JSON responses, parsing time increased massively (multiple-fold slowdown) compared to protobuf. Even moderately nested messages take much longer to read, causing visible UI delays and frame drops.

I wrote a custom implementation of WireTypeAdapterFactory (mainly to change enum handling), and even after caching all RuntimeMessageAdapter instances, performance is still very slow.

I also tested with Moshi + WireJsonAdapterFactory, and while slightly faster, it still suffers from the same fundamental cost — JSON decoding of Wire messages is an order of magnitude slower than protobuf decoding.

🔍 What I Have Already Tried
✔️ 1. Caching RuntimeMessageAdapter instances
I verified that RuntimeMessageAdapter.create() is not being called repeatedly.
All adapters are cached in a global map. → No major improvement.

✔️ 2. Custom TypeAdapter with optimized field lookup
I built a custom implementation of WireTypeAdapterFactory that includes:
Cached field maps (nameToField)
Pre-bound setter lambdas to avoid reflection inside FieldBinding.set()
Inline fast paths for primitives (avoid TypeAdapter.read() for boolean/int/double/string)

✔️ 3. Switching from Gson → Moshi
Tried WireJsonAdapterFactory:

But, unfortunately none of this worked.

Example Proto (dummy simplified version)

message WidgetResponse {
    WidgetConfig widget_config = 1;
    oneof widgets {
        Widget1 widget_1 = 2;
        Widget2 widget_2 = 3;
    }
}

message WidgetConfig {
    WidgetType widget_type = 1;
}

enum WidgetType {
    WIDGET_TYPE_1 = 0;
    WIDGET_TYPE_2 = 1;
}

message Widget1 {
    string title = 1;
}

message Widget2 {
    string title = 1;
    string subtitle = 2;
}

Please help me out in fixing this problem.

[JakeWharton]

This seems as expected to me. The fact that it causes UI problems seems to indicate you are doing serialization on the UI thread, as opposed to a background thread.

The JSON serialization and deserialization is dynamic and based on reflection, whereas the protobuf serialization and deserialization is static and based on code generation. I would not expect them to be anywhere near each other in terms of performance.

[Zogesh]

I’m using Retrofit, so it uses background Dispatcher threads for serialization/deserialization. None of the JSON serialization/deserialization happens on the UI thread. Otherwise, it would have blocked the App's UI for that time, but it's not the case

[Zogesh]

@JakeWharton I believe there was a miscommunication in how the issue was explained earlier.

If I use normal Kotlin data classes with @SerializedName / @ Expose and let Gson or Moshi parse them directly, the JSON parsing time is very fast.

The performance slowdown only happens when using the Wire-generated classes with @WireField.

Why is it so?

For example I have created a Kotlin data class using @ Expose and @SerializedName as we do traditionally to parse JSON responses. And on the other handle I have used the @WireField generated classes as well. But the difference in parsing both responses is drastic. Attaching screenshot for it. I am attaching both data classes, proto message and the api response as well.

parsing_test.json

widget_response_proto.txt

WidgetResponse_SerializedName_kt.txt

WidgetResponse_WireField_kt.txt

[JakeWharton]

Can you share the JMH code you're benchmarking with?

I would expect the warmed-up performance of both mechanisms to be similar. Essentially, both are building up a list of TypeAdapters for each field and then using reflection to get their values. The Wire-based one has to apply the proto JSON semantics (defined here), so I would expect a tiny bit of overhead but not a ton.

Plus with streaming serialization we generally expect the cost to be amortized over the cost of the network itself which should be slower. I would not expect anything like a 10x performance difference between the two, however.