:question: Has the cost of using _lazy_ on the JVM...

# stdlib

[darkmoon_uk]

❓ Has the cost of using lazy on the JVM changed at all since

this talk▾

at Google in 2019?

The gist of this talk is to warn developers against using lazy (and possible other Property Delegation) - the foundation of their argument appears to be that use of reflection in property delegation is too costly for most use cases. Unfortunately they don't give any examples of where the 'tipping point' of complexity lies; where lazy does become worth it.

This has put my team off from using lazy even for cases where moderately complex objects are being created.

I'm suspect of two things in this talk: firstly their poor choice of example - obviously it's going to be inefficient to use this to allocate an Int, but what about smaller-to-moderately sized classes? No benchmarks provided or discussion of initial lazy cost vs. subsequent lazy where presumably some aspects of any reflection would have become cached.

Thoughts?

[ephemient]

property delegates have been optimized, https://blog.jetbrains.com/kotlin/2019/12/what-to-expect-in-kotlin-1-4-and-beyond/#:~:text=%23delegated-properties

[ephemient]

the cost of wrapping and synchronization is still there though

[jw]

you can avoid synchronization by passing a strategy parameter

[jw]

but no the cost has not changed

[jw]

lazy is a heavyweight construct and should itself be used for heavyweight objects

[darkmoon_uk]

That much is understood; I wouldn't use it for a simple data class instantiating only a few fields. Still, the Google 'warning' would have been a lot more informative with examples of objects at the 'tipping point' of complexity; above which it would make sense to use lazy. The Int example was pretty unhelpful (by their own admission!?).

[darkmoon_uk]

"but no the cost has not changed"

You mean beside the cases stated in the Kotlin 1.4 release notes, since the 2019 talk?