hi! I’m migrating to apollo kotlin v3 and I need to make a decision between `responseBased` and `ope...

# apollo-kotlin

[Volodymyr Korniienko]

hi! I’m migrating to apollo kotlin v3 and I need to make a decision between responseBased and operationBased codegen. responseBased is claimed to be more performant but generates tons of code that may affect class loading and compilation time. Therefore I’m wondering is there any performance analysis of these two methods based on response size/nested fragments count/any other metric?

[mbonnin]

Sadly not at this point.

[mbonnin]

It depends a lot how you use fragments and merged fields

[mbonnin]

One thing to note is that while class loading might be slower, parsing with responseBased models is faster because they can stream the response

[mbonnin]

So it's all a tradeoff really.

[mbonnin]

My rule of thumb there is that operationBased is more predictable and will give stable performance so it's a good default to start with. responseBased will give you more type information and parsing speed but it also comes with gotchas so it's a good thing to explore once you're comfortable with operationBased

[Volodymyr Korniienko]

Thank you Martin, will proceed with operationBased then.

[mbonnin]

Let us know how that goes! I've been wanting to write benchmark for this but benchmarking is hard and I think any meaningful comparison will need to be on a real-life codebase. If you ever end up trying responseBased , let me know how that works, we can add that to the docs somewhere

[Yang]

I use responsedBased with flattenModels.set(true) which has been working quite well in a KMM project