Simplify `instantiated_t` by specializing for `std::tuple` to improve code clarity and reduce compilation time

[Kim-J-Smith]

Hi,

I noticed that instantiated_t is widely used in the codebase. The current implementation works well, but it is somewhat indirect and may introduce unnecessary compilation overhead.

Current implementation:

template <template <class...> class T, class TL, class Is, class... Args>
struct instantiated_traits;
template <template <class...> class T, class TL, std::size_t... Is,
          class... Args>
struct instantiated_traits<T, TL, std::index_sequence<Is...>, Args...>
    : std::type_identity<T<Args..., std::tuple_element_t<Is, TL>...>> {};
template <template <class...> class T, class TL, class... Args>
using instantiated_t = typename instantiated_traits<
    T, TL, std::make_index_sequence<std::tuple_size_v<TL>>, Args...>::type;

Proposed simplified implementation:

template <template <class...> class T, class TL, class... Args>
struct instantiated_traits;
template <template <class...> class T, class... Ts, class... Args>
struct instantiated_traits<T, std::tuple<Ts...>, Args...>
    : std::type_identity<T<Args..., Ts...>> {};
template <template <class...> class T, class TL, class... Args>
using instantiated_t = typename instantiated_traits<T, TL, Args...>::type;

Why this is better:

• Clearer intent – the code directly expresses "append the types from the tuple".
• Faster compilation – avoids instantiating std::make_index_sequence and repeated std::tuple_element lookups.
• Less template bloat – only one partial specialization is needed.

Important prerequisite:
The new version requires that TL is exactly std::tuple<...>. From my analysis of the current codebase, all existing uses of instantiated_t pass a std::tuple (e.g., C::overload_types, F::convention_types, etc.). So this condition holds.

Would you be open to accepting a PR that makes this change?

[mingxwa]

Hi @Kim-J-Smith,

Thanks for bringing this up.

One key detail to consider is that instantiated_t needs to remain compatible with all 'tuple-like' types (like std::pair), as defined in the Proxy specification > ProFacade requirements. Because of this, I'm opposed to a direct replacement since it would break support for those types.

What we could do instead is keep the existing implementation and add a specialization specifically for std::tuple. This would preserve compatibility while potentially speeding up the most common use cases.

Since I want to ensure we only add complexity where it provides a clear benefit, would you be interested in running some compile-time benchmarks? If you can provide some data showing a performance improvement, I'd be very glad to help you land a specialization for it!

Mingxin

[Kim-J-Smith]

Thanks for your feedback.

I fully understand that instantiated_t must remain compatible with all tuple‑like types as required by the ProFacade specification.

The new implementation below does not simplify instantiated_t — in fact it adds some complexity — but it does provide a specialization for std::tuple to improve compile‑time performance for the most common case.

template <template <class...> class T, class TL, class Is, class... Args>
struct instantiated_traits;
template <template <class...> class T, class TL, std::size_t... Is,
          class... Args>
struct instantiated_traits<T, TL, std::index_sequence<Is...>, Args...>
    : std::type_identity<T<Args..., std::tuple_element_t<Is, TL>...>> {};

template <template <class...> class T, class TL, class... Args>
struct instantiated_traits_helper : instantiated_traits<
    T, TL, std::make_index_sequence<std::tuple_size_v<TL>>, Args...> {};
template <template <class...> class T, class... Ts, class... Args>
struct instantiated_traits_helper<T, std::tuple<Ts...>, Args...> 
    : std::type_identity<T<Args..., Ts...>> {};

template <template <class...> class T, class TL, class... Args>
using instantiated_t = typename instantiated_traits_helper<T, TL, Args...>::type;

To evaluate whether the added complexity is worthwhile, I wrote a simple compile‑time benchmark. You can find the run here and the full report here.

Compile‑time results (in microseconds):

Conventions	Old Implementation (us)	New Implementation (us)	Improvement
3	28,247.60	25,756.40	+9.7%
10	50,086.60	38,855.40	+28.9%
30	155,814.00	91,321.80	+70.6%
100	1,711,836.20	387,899.80	+341.3%
200	10,181,264.60	1,066,714.60	+854.5%

As the number of conventions grows, the improvement becomes dramatic — up to 8.5x faster for 200 conventions.

Given these numbers, do you think the extra complexity is justified? I’d be happy to polish the implementation or provide more benchmarks if needed.

[mingxwa]

Hi @Kim-J-Smith,

Thank you for taking the time to put together these benchmarks! Those numbers are incredibly convincing.

Please go ahead and open a PR with your new instantiated_traits_helper implementation. Since the std::tuple case is already thoroughly exercised by the current codebase, you likely won't even need to add any new unit tests for this.

Looking forward to reviewing your PR!

Mingxin