Calling macros across projects in dbt - Time & Space Complexity

Time Complexity: Calling macros across projects

O(n)

Understanding Time Complexity

When using dbt, calling macros from other projects can affect how long your code takes to run.

We want to know how the time to run grows when calling macros across projects.

Scenario Under Consideration

Analyze the time complexity of the following dbt code snippet.

    {{
      project_macro('argument')
    }}

    {% macro project_macro(arg) %}
      {{ other_project.some_macro(arg) }}
    {% endmacro %}
    

This code calls a macro from another project inside a macro in the current project.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Calling a macro from another project once per invocation.
• How many times: Once each time the macro is called in the model or another macro.

How Execution Grows With Input

Each time you call the macro, dbt looks up and runs the other project's macro.

Input Size (n)	Approx. Operations
10	10 macro calls, 10 cross-project lookups
100	100 macro calls, 100 cross-project lookups
1000	1000 macro calls, 1000 cross-project lookups

Pattern observation: The time grows directly with how many times you call the macro.

Final Time Complexity

Time Complexity: O(n)

This means the time to run grows linearly with the number of macro calls across projects.

Common Mistake

[X] Wrong: "Calling a macro from another project is instant and has no cost."

[OK] Correct: Each cross-project macro call requires dbt to find and run that macro, which takes time proportional to how often it is called.

Interview Connect

Understanding how calling macros across projects affects performance shows you can think about how code structure impacts run time, a useful skill in real projects.

Self-Check

"What if the macro called from the other project itself calls multiple macros inside it? How would the time complexity change?"