Non-nullable types by default in Kotlin - Time & Space Complexity

Time Complexity: Non-nullable types by default

O(1)

Understanding Time Complexity

We want to see how the program's steps grow when using non-nullable types in Kotlin.

How does Kotlin handle checking for null values as the program runs?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

fun printLength(text: String) {
    println(text.length)
}

fun main() {
    val input: String = "Hello, Kotlin!"
    printLength(input)
}
    

This code prints the length of a non-nullable string passed to a function.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Accessing the length property of a non-nullable string.
• How many times: Exactly once per function call.

How Execution Grows With Input

Getting the length of a string takes the same amount of time no matter how long the string is.

Input Size (n)	Approx. Operations
10	1
100	1
1000	1

Pattern observation: The operation count stays the same even if the string is longer.

Final Time Complexity

Time Complexity: O(1)

This means the time to get the string length does not grow with input size.

Common Mistake

[X] Wrong: "Checking for null in Kotlin slows down the program as the input grows."

[OK] Correct: Kotlin's non-nullable types are checked at compile time, so no extra work happens at runtime as input size grows.

Interview Connect

Understanding how Kotlin handles null safety helps you write safer code without worrying about slowing down your program.

Self-Check

"What if the function accepted a nullable String instead? How would the time complexity change?"