Apollo parsing on a low end device has lots of non...

# apollo-kotlin

[Sinan Kozak]

Apollo parsing on a low end device has lots of non running blocks. is there any known explanation about it. The parsing also takes more time than actual network operation. What is the best practice to investigate something like this?

[mbonnin]

The parsing also takes more time than actual network operation.

Double checking you're measuring both parsing and networkd completely separately? By default, fromJson reads from a BufferedSource so it will do network I/O.

[Sinan Kozak]

I can share the rest of the systrace. This part starts after interceptors done with network requests.

Btw . I didn't expect to find any performance issue about Apollo parsing but here I am

[Sinan Kozak]

I started by investing why there are non running parsing operations. There are not locks or something like that

[mbonnin]

The NetworkEngine only does the "handshake" part of the HTTP request, reading the body is made at the same time as the parsing

[mbonnin]

If you have no fragment, parsing should be amortized. With fragments, the situation is more complicated because we need to buffer some of the data

[mbonnin]

(because we need to "rewind" the stream)

[Sinan Kozak]

I think there are fragments. Lots of them. I am new in this part of the app. What should I look for

[mbonnin]

Is that even possible to have "non-running" blocks? I understand the white blocks above to be time spent in HomePage$fromJson (where exactly, I have no idea)

[mbonnin]

> What should I look for
I would first try to isolate the network from the parsing:
1. measure the network time with a plain OkHttp call, make sure to read all the body to the last byte.
2. Dump that body somewhere in memory and call fromJson on it

[Sinan Kozak]

Systrace block also says it was running only 50% of time. %40 we're not running

[mbonnin]

not running means "blocked on IO" I think ?

[Sinan Kozak]

If it is buffered, is it possible that it waits for network response?

[Sinan Kozak]

I will check that as much as I can. Since they run in block, I don't have clear answers why cant it move to next bit of parsing

[mbonnin]

(aside: this is the doc for how to read without `ApolloClient`, just from in-memory data)

[mbonnin]

If it is buffered, is it possible that it waits for network response?

Could be, the "bufferization" is decided "by fragment.

query {
  user {
    name
    bio
    # buffering happens here
    ... on Admin {
    }
  }
}

[mbonnin]

I would dump a response into an okio Buffer in RAM, create a JsonReader from it and measure the parsing time with operation.parseJsonResponse(jsonReader)

[mbonnin]

I expect that to use 100% of one core

[mbonnin]

(or something close)

[Sinan Kozak]

Yes every bit of those blocks are fragment

[Sinan Kozak]

I will do that. Just to put expectations right, buffer approach supposed to be faster, right?

[mbonnin]

Yea, it's not doing any networking so it should be faster

[Sinan Kozak]

Let me experiment with that.

[Sinan Kozak]

I am confused a bit about buffer. if response is written into buffer, why request process is long? should request itself fishes after first byte and rest of the logic executes in parsing part?

if it is really dummy question, I am confused about what happens when

[mbonnin]

Depends where you're putting your probes and what you're calling a request process

[mbonnin]

I would have expected to see more of Apollo in your trace stack though, looks like apollo_fetch_HomeFeed is calling ResponseAdapter$Data.fromJson() directly?

[Sinan Kozak]

this is systrace added by codegen only to our code. I will include apollo classes in next run

[Sinan Kozak]

also our apollo version is 4.1.1 quite old.

[mbonnin]

This part hasn't moved for some time, I wouldn't expect much difference on newer versions (but sitll worth a try!)

[Sinan Kozak]

those red parts the empty pieces from first run. so it is not sleeping. thats good news.

[Sinan Kozak]

it looks like 4-5 layers of fragments

[mbonnin]

Can you share some rough numbers? Size of the JSON, time to parse it?
FWIW, we are tracking JSON parsing time here

[Sinan Kozak]

Network response is around 50k bytes. Let me check the Jaso size in Monday.

Tbh at this moment, I think it is the way we use the Apollo and how inefficient low end devices.

[mbonnin]

Sonething else that'd be interesting would be to compare to something like Moshi. It should typically be in the same range although apollo slightly slower due to fragments

[Sinan Kozak]

I can also experiment that. Is Kotlinx serialization an option?

[mbonnin]

Sure. I said Moshi because the JsonReader code was taken from Moshi but kotlinx serialization should be relatively similar