Since there’s a reified `serializer<T>()` that throws if no serializer is found, why isn’t there a `...

# serialization

[Marcello Galhardo]

Since there’s a reified serializer<T>() that throws if no serializer is found, why isn’t there a serializerOrNull<T>() as well? I know there’s a serializerOrNull(KType), but as I understand it, typeOf<T>() relies on reflection and has performance implications.

[Marcello Galhardo]

Reference: https://kotlinlang.org/api/kotlinx.serialization/kotlinx-serialization-core/kotlinx.serialization/serializer-or-null.html

[ephemient]

typeOf<T>() is an intrinsic, what performance implications?

[ephemient]

it does require constructing kotlin.reflect implementation objects but it isn't runtime reflection

[ephemient]

and that got caching added a while ago, https://github.com/JetBrains/kotlin/commit/fdd541c1e9cdccd6f96c49e24844f9b8450273a2

[eneim]

Hi @ephemient, I would like to follow-up about the performance of typeOf. In my observation, for the very first cold start,

// Mimicing the Json.decodeFromStream(InputStream) extension, but using MyClass::class.java instead.
json.decodeFromStream(
    deserializer = json.serializersModule.serializer(MyClass::class.java),
    stream = dataInputStream,
)

is way faster than

// Same as the Json.decodeFromStream(InputStream) extension
json.decodeFromStream(
    deserializer = json.serializersModule.serializer(typeOf<MyClass>()).cast(),
    stream = dataInputStream,
)

(I'm building Android app and using macro-benchmark to get test this).

I understand the result of typeOf<MyClass>() is cached, but for the critical cold start it is still significant (for one class, it is <2ms versus >=20ms or slower in old devices).

Beside the multi-platform nature, is there any other advantages of the later that I should know of? I'm considering to use the serializer(T::class.java) for my Android-only application but it could be great to understand if this is not a over-optimization.