Question

0

203

Visualizações

What are the performance differences between all the ways to declare a constant in Kotlin?

Since Kotlin doesn't allow you to directly declare constants inside a class like static members in Java, we have a couple of options on how to do it in Kotlin. My question is, what are the performance costs of each option, and which one is cheaper? I don't want to know which one is more readable or considered best-practice, I only want it from a performance perspective.

Option 1: Use a companion object

So a code that looks like this:

class Thing {
    companion object {
        const val TAG = "Thing"
    }

   ...
}

In Java looks like this:

public final class Thing {
   public static final String TAG = "Thing";
   public static final Thing.Companion Companion = new Thing.Companion((DefaultConstructorMarker)null);

   public static final class Companion {
      private Companion() {
      }

      public Companion(DefaultConstructorMarker $constructor_marker) {
         this();
      }
   }

   ...
}

It creates this inner class Companion and instantiates it. How costly is this?

Option 2: Declare it as a top-level variable

So this:

const val TAG = "Thing"
class Thing {
   ...
}

Becomes this:

public final class ThingKt {
   public static final String TAG = "Thing";
}

public final class Thing { ... }

It creates a new class with a static member. How different is this than using an object to store it?

Option 3: Use an external object

Like so:

object ThingConstants {
    const val TAG = "Thing"
}

class Thing { ... }

Which in Java looks like this:

public final class ThingConstants {
   public static final String TAG = "Thing";
   public static final ThingConstants INSTANCE;

   ...  // Private constructor
}

public final class Thing { ... }

So similar to declaring as top-level, except the created class has an INSTANCE field that is initialized in a private constructor. How costlier is this compared to using a top-level variable?

Option 4: Drop the const modifier

So you just use the good old val:

class Thing {
    val TAG = "Thing"
    
    ...
}

This is a mystery to me. It doesn't create any additional classes, but doesn't reap the benefits of the const modifier either. This means each instance of the class is going to have its own instance of TAG, as well as generating getters and setters for it too, right? But I also read that the JVM optimizes it as a constant. So there is more to this option than I initially thought.

over 4 years ago · Santiago Trujillo

1 Respostas

Responde à pergunta

0

Responde à pergunta

Encontrar trabalhos remotos

Accepted Answer · 2022-03-28T17:39:29.749Z

Options 1-3 are the same for performance because they are all const , so they are inlined wherever they are used at compile time.

Option 4 does not create duplicate instances of String for each instance of the class. Instead, each instance of the class will have a member field that points to the same shared instance. Performance-wise, you technically have to call a getter method every time you fetch, but I'd expect modern VMs to optimize for that overhead at runtime.

Options 1-3 create additional Java class definitions, so there is a bit more initial memory overhead for them. But if you already have other members on those objects or higher file levels, you already have those classes anyway. Option 4 has an extra field in the class, so it might weigh more if there are many instances of the class.

0

203