Is there a way to avoid object instantiation for a simple cl

Question

Is there a way to avoid object instantiation for a simple class like `data class Point val x Int val y Int ` In an API with lots of operations on such `Point`s there is lots of `Point` objects being created Changing the API to operate on x and y parameters separately without a `Point` class avoids the overhead but makes the API less clean Is there some language feature that can help here I am looking for something like inline classes but for two member properties

Joffrey · Answer

Value classes for multiple properties are not supported yet In your specific case you could work around it if you know the full dimension of the grid and if it fits by using a 1 dimensional index to represent the position in the 2D grid EDIT you could also just store these 2 `Int` in the low and high bits of a `Long` which doesn t require knowing the max width

Joffrey · Answer

Something like this for instance ```const val GRID WIDTH = 200 or whatever is your grid size value class Point private val index Int val x Int get = index GRID WIDTH val y Int get = index GRID WIDTH ```

Marcin Wisniowski · Answer

Although I used `Int` in my example for simplicity my `Point` actually takes `Double` coordinates So I cannot do such an operation

Marcin Wisniowski · Answer

Maybe I can find another way to fit two `Double` values into a single variable somehow

Joffrey · Answer

gt Although I used `Int` in my example for simplicity my `Point` actually takes `Double` coordinates So I cannot do such an operation And here goes the workaround out the window smile

Joffrey · Answer

This workaround only works with int where you can enumerate accurately those possibilities row by row but I m not sure you can do something equivalent with doubles Did you measure the impact of the extra `Point` objects though

Marcin Wisniowski · Answer

It s used during animations of multiple objects there could be hundreds of `Point` objects created every frame But even if there was no impact this would be interesting to solve

Joffrey · Answer

gt It s used during animations of multiple objects there could be hundreds of `Point` objects created every frame Still doesn t mean it s a problem It really depends on how you use these objects what their lifecycle is For instance if you use them as temporary local variables they will be allocated on the TLAB and will be very cheap gt But even if there was no impact this would be interesting to solve I think multi property value classes will come at some point so the Kotlin team is already working on it This will be especially true when project Valhalla comes in In the mean time we re stuck with regular classes or workarounds that manage to cram everything in a single field smile of course you can also pass the 2 values as argument to all functions but that doesn t solve the problem for return values

Michael Böiers · Answer

Are you sure that the instantiation will be a performance problem Modern VMs are pretty good at reusing small objects like that

Michael Böiers · Answer

Of course you could create them all through a factory method and add some sort of cache in there either caching all the points or just the most recently used

Michael Böiers · Answer

But in essence like I said in the previous comment the VM is already doing something like that for all objects My advice would be to go ahead with the data class and then if performance becomes an issue profile the application

Marcin Wisniowski · Answer

< Michael Böiers> You are right this is not a real issue but I was interested in the problem itself

Marcin Wisniowski · Answer

I managed to make a `Point x Double y Double ` value class See it at your own risk <https pl kotl in camTTpjz5>

Joffrey · Answer

Btw I realized my initial solution could have just been storing the two ints in the high and low bits of a single long without even knowing the grid size and using ` ` and ` `

Joffrey · Answer

gt I managed to make a `Point x Double y Double ` value class Now the question is aren t all those operations actually slower than just allocating and garbage collecting `Point` instances

Michael Böiers · Answer

Only a profiler can give you that answer

Marcin Wisniowski · Answer

I m not actually going to use it but it was fun to implement

Marcin Wisniowski · Answer

gt I think multi property value classes will come at some point < Joffrey> Is there a KEEP for that

Michael Böiers · Answer

You can still try it later I like that it s fully compatible with the straight forward implementation

Joffrey · Answer

There is this issue to track it The initial KEEP for value classes also contains some information You can start from this section And carry on to the Valhalla part and the actual section about multiple fields just below

ephemient · Answer

you can mux two Float into one Long e g `value class FloatPair` generated by <https github com ephemient kotlin numeric|https github com ephemient kotlin numeric> but unfortunately Double is 64 bits and there is no 128 bit primitive so you can t pull the same trick

ephemient · Answer

IMO Float is much more reasonable than double with limited precision that you wrote there

Marcin Wisniowski · Answer

<https androidx tech artifacts compose ui ui geometry 1 0 0 beta02 source androidx compose ui geometry Offset kt html> I just found this while working on something unrelated looks like what I did except better Maybe I wasn t so crazy after all

ephemient · Answer

<https github com androidx androidx blob androidx main compose ui ui util src commonMain kotlin androidx compose ui util InlineClassHelper kt> packFloats and unpackFloat 12 do the same thing I do in FloatPair which is to use the raw bit representation of the Float

ephemient · Answer

what you have with Point is some sort of self invented floating point format but with decimal base and less precision