Runtime cost of dynamic type resolution in C Sharp (C#) - Step-by-Step Execution

Concept Flow - Runtime cost of dynamic type resolution

Start: Call dynamic method

↓

Runtime checks actual type

↓

Find matching method or property

↓

Invoke method/property dynamically

↓

Return result

↓

End

When using dynamic types, the program checks the actual type at runtime, finds the right method or property, then calls it, which adds extra steps compared to static calls.

Execution Sample

C Sharp (C#)

dynamic obj = "hello";
int length = obj.Length;
Console.WriteLine(length);

This code uses a dynamic variable to get the length of a string, resolving the property at runtime.

Execution Table

Step	Action	Evaluation	Result
1	Assign "hello" to dynamic obj	obj holds string "hello"	obj = "hello"
2	Access obj.Length	Runtime checks obj's actual type (string)	Finds string.Length property
3	Invoke Length property getter	Calls string.Length	Returns 5
4	Assign result to int length	length = 5	length = 5
5	Print length	Console outputs 5	Output: 5

💡 All steps complete; dynamic resolution done at step 2 causing runtime overhead

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
obj	unassigned	"hello"	"hello"	"hello"	"hello"	"hello"
length	unassigned	unassigned	unassigned	5	5	5

Key Moments - 3 Insights

Why does accessing obj.Length take longer than a normal string.Length call?

Because at step 2 in the execution_table, the program must check obj's actual type at runtime and find the correct member, which adds extra work compared to direct calls.

Does the variable obj change its type during execution?

No, obj holds a string from step 1 onward, but the compiler treats it as dynamic, so type resolution happens at runtime (see variable_tracker for obj's value).

What causes the runtime cost in dynamic type resolution?

The runtime cost comes from the lookup and invocation steps (step 2 and 3) where the program must find and call the correct method/property dynamically instead of using static binding.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of length after step 3?

A unassigned

B 5

C "hello"

D null

💡 Hint

Check the 'length' variable in variable_tracker after step 3; it is assigned at step 3.

At which step does the runtime check the actual type of obj?

A Step 4

B Step 1

C Step 2

D Step 5

💡 Hint

See execution_table step 2 where it says 'Runtime checks obj's actual type'.

If obj was statically typed as string, which step would be skipped?

A Step 2

B Step 3

C Step 1

D Step 5

💡 Hint

Dynamic type resolution at step 2 is the extra cost; static typing skips this.

Concept Snapshot

dynamic type resolution in C# means the program finds the actual type and member at runtime.
This adds overhead compared to static calls.
Example: accessing obj.Length when obj is dynamic triggers runtime lookup.
Steps: check type -> find member -> invoke -> return result.
Use dynamic only when necessary due to this cost.

Full Transcript

This example shows how dynamic type resolution works in C#. When a variable is declared dynamic, like obj, the program does not know its type at compile time. Instead, at runtime, it checks the actual type of obj, which is a string in this case. Then it finds the Length property on the string type and calls it. This process adds extra steps compared to normal static calls, causing runtime cost. The execution table traces each step: assigning the string, checking type, invoking the property, assigning the result, and printing it. The variable tracker shows obj holds "hello" throughout, and length gets assigned 5 after the property call. Key moments clarify why dynamic calls are slower and how type checking happens at runtime. The quiz tests understanding of when type checking occurs and variable values at each step. Remember, dynamic is powerful but slower due to this runtime resolution.