diff --git a/docs/tuning.rst b/docs/tuning.rst
index 2a25a7eff..652dfea39 100644
--- a/docs/tuning.rst
+++ b/docs/tuning.rst
@@ -144,6 +144,34 @@ treated as equally important.
     .add_int64_power_of_two_axis("Elements{io}", nvbench::range(16, 28, 4));
 
 
+When you define a type axis that's annotated as :code:`{ct}`, you might want to consider optimizing 
+the build time. Many variants are going to be build, but the search is considering one compile-time 
+use case at a time. This means, that if you have many types to tune for, you'll end up having 
+many specializations that you don't need. To avoid this, for each compile time axis, you can 
+expect a `TUNE_AxisName` macro with the type that's currently being tuned. For instance, if you
+have a type axes :code:`T{ct}` and :code:`OffsetT` (as shown above), you can use the following
+construct:
+
+.. code:: c++
+
+  #ifdef TUNE_T
+  using types = nvbench::type_list<TUNE_T>;
+  #else
+  using types = all_types;
+  #endif
+
+  #ifdef TUNE_OffsetT
+  using offset_types = nvbench::type_list<TUNE_OffsetT>;
+  #else
+  using offset_types = nvbench::type_list<int32_t, int64_t>;
+  #endif
+
+
+This logic is automatically applied to :code:`all_types`, :code:`offset_types`, and 
+:code:`fundamental_types` lists when you use matching names for the axes. You can define 
+your own axis names and use the logic above for them (see sort pairs example).
+
+
 Search Process
 --------------------------------------------------------------------------------