newbie here. I've got a class that I'm serializing...

# serialization

[y]

newbie here. I've got a class that I'm serializing to json using kotlinx.serialization. the class is very complex and I would like to only serialize some of its fields.
can I do this efficiently, while avoiding costly intermediate values as much as possible?

[andylamax]

You can mark those fields with @Transient just make sure that, their are optional fields during constructing the class

[CLOVIS]

Why are intermediate values costly?

[Johann Pardanaud]

You can also write a custom serializer I you find the @Transient annotation too limited.

The costly intermediate values, in this case, would be surrogate classes right?

Fortunately, you can write a custom serializer without surrogates:

*<https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/serializers.md#hand-written-composite-serializer

|Hand-written composite serializer>*

There are some cases where a surrogate solution does not fit. Perhaps we want to avoid the performance implications of additional allocation, or we want a configurable/dynamic set of properties for the resulting serial representation. In these cases we need to manually write a class serializer which mimics the behaviour of a generated serializer.

[Arjan van Wieringen]

In those cases I’d just write a DTO which is a simple data class to which you can convert and back. And serialize that DTO. Easy serialization, and full control to you as developer for managing the complex class. Don’t make the complex class more complex by making the serialization part of it

[y]

that seemed like the naive solution to me and I expected the conversion to add significant overhead (that's what I meant by costly intermediate values - I'm a Kotlin newbie, sorry!).
so simply defining a new "plain old data" class with fewer properties and serializing that would achieve this? I don't even need to deserialize, so I don't need the conversion back.

[Arjan van Wieringen]

Well suit yourself if you think that is the naive solution. :)

Have you measured what the cost is of those intermediate values and whether or not they exceed your threshold? How does it stack up to the increased complexity of a complex class itself?

[y]

I did not measure. I'll go ahead and benchmark now.

[CLOVIS]

Shallow copying (like surrogate classes) are essentially free. At least they're much less expensive than the serialization/deserialization process.

[y]

@CLOVIS that is something I'm still having a hard time adjusting to.
same with whether or not combining iterators is "expensive" or not: when exactly it is preferable to avoid creating another intermediate collection, when it's worth using a Sequence over an iterator... all kinds of things that are probably meaningless premature optimization scares

[Arjan van Wieringen]

Just don't prematurely optimize too much. It is a waste of time and typically makes code harder to understand. Just write understandeable code, and optimize when needed. Just know that there are a lot of ways to optimize, and it is better to know what to optimize (by running into performance issues) and fix it then try to make the fastest solution from the start.

[Arjan van Wieringen]

Especially since you say you're a newbie it is probably pretty difficult to know which parts are inefficient a priori.

[CLOVIS]

Always remember: it is easier to make readable code more efficient, than to read prematurely optimized code