Skip to content

[Optimization] Optimize build-time for clang and older gcc #17

Closed

Description

@mcencora

TLDR; Consider optimizing build-time for all single-argument templated constructors, and assignment operators by early-out with an SFINAE !is_same<std::remove_cv_ref_t<Arg>, expected>

Long story:

When instantiating a class that wraps (or derives from) expected<T, E>, it usually must determine whether expected is copyable/moveable via appropriate type traits.

Compiler/std lib does this internally by performing overload resolution e.g. for expected<T, E>(const expected&) which triggers template argument substitution for all constructors with matching parameters list, including the ones that will never be selected because they are templates (on tie template function always lose to non-template function).
Template argument substitution can be quite costly when it involves complex SFINAE expressions like enable_from_other_expected_t.
We can optimize such scenarios by short-circuting the SFINAE checks for given template function in case it would match parameters of one of SMFs.

gcc 9+ already optimizes such scenarios internally, but latest clang still doesn't.

Example below illustrates the problem and a workaround:

#include <type_traits>

template <typename T>
constexpr auto busyLoop()
{
    unsigned sum = 0u;
    unsigned arr[200'000] = {};
    for (auto c : arr)
    {
        sum += c * c / (c + 1u) ^ c;
    }
    return sum == 0;
}

template <typename T>
constexpr bool some_complex_condition_v = busyLoop<T>();

template <typename T>
struct Foo
{
    Foo(const Foo&) = delete;

#ifndef WORKAROUND
    template <typename U, std::enable_if_t<some_complex_condition_v<U>> * = nullptr>
    Foo(const U&);
#else
    template <typename U, std::enable_if_t<!std::is_same_v<U, Foo>>* = nullptr, std::enable_if_t<some_complex_condition_v<U>> * = nullptr>
    Foo(const U&);
#endif
};

static_assert(!std::is_copy_constructible_v<Foo<int>>);

On my machine with clang-20 following code compiles in about ~1.3s, while it takes <0.1s when compiled with -DWORKAROUND

Activity

  1. X1aomu commented on Jul 15, 2025

    @X1aomu
    Contributor

    Thanks very much! And sorry for late response.

    It took me some time to fully understand the issue, but I think I finally got it now. I’ll start thinking about how to fix it next.

  2. mcencora commented on Jul 16, 2025

    @mcencora
    Author

    FYI I've just learned that gcc's optimization for such scenario is debated in https://wg21.link/P3606

  3. X1aomu commented on May 21, 2026

    @X1aomu
    Contributor

    @mcencora

    I have a brief implementation. However I didn't find significant compile time different with MSVC 142 and LLVM 22.

    Are you still using an old version (it's ok to support some reasoning old version)? Could you share a real benchmark example?

  4. X1aomu commented on May 21, 2026

    @X1aomu
    Contributor

    I've seen difference with LLVM 19. About 25% faster :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions