<type_traits>: Improve _Invoke_traits throughput

[StephanTLavavej]

STL/stl/inc/type_traits

Lines 1685 to 1696 in 19067f6

	template <class... _Types>
	struct _Invoke_traits<void_t<decltype(_STD invoke(_STD declval<_Types>()...))>,
	_Types...> { // selected when _Callable is callable with _Args
	using type = decltype(_STD invoke(_STD declval<_Types>()...));
	using _Is_invocable = true_type;
	using _Is_nothrow_invocable = bool_constant<noexcept(_STD invoke(_STD declval<_Types>()...))>;
	template <class _Rx>
	using _Is_invocable_r = bool_constant<disjunction_v<is_void<_Rx>, is_convertible<type, _Rx>>>;
	template <class _Rx>
	using _Is_nothrow_invocable_r = bool_constant<
	conjunction_v<_Is_nothrow_invocable, disjunction<is_void<_Rx>, _Is_nothrow_convertible<type, _Rx>>>>;
	};

The compiler front-end team has advised us that repeating _STD invoke(_STD declval<_Types>()...) here is unusually expensive. Preserving the distinction between _Callable, _Args... and replacing this with the equivalent _Invoker::_Call() expression should significantly improve throughput (~25% faster).

[lozinska]

Hi! Can I work on this issue?

[StephanTLavavej]

Sure! When I initially looked at this issue, I thought that the _Types... parameter needed to be refactored into _Callable, _Args.... Looking at it again, that refactoring might not be necessary; you should be able to pass the _Types parameter pack to _Invoker directly. (For example, if Things is a parameter pack containing two types, you can say pair<Things...> and it’ll compile just fine; the pack expansion works with pair<First, Second>.)

Please let us know if you need further information; invoke is one of the more complicated bits of template metaprogramming in the STL, and currently we generate _Invoker with a macro so it’s a bit hard to read (which we’ll be able to avoid in the future).

[lozinska]

Ok, thank you!

[lozinska]

Hi Stephan T. Lavavej (@StephanTLavavej) I have been looking through this issue and I have question. So as I understand I will need to replace invoke(_STD declval<_Types>()...) with invoke(pair<_Types>()...). Is it correct?
By the way can i use https://godbolt.org/ in order to check if I made right corrections?

[lozinska]

Stephan T. Lavavej (@StephanTLavavej) sorry I probably ask very general question. Let me investigate more on this issue and then ask questions

[StephanTLavavej]

So as I understand I will need to replace invoke(_STD declval<_Types>()...) with invoke(pair<_Types>()...). Is it correct?

No - the suggested replacement is _Invoker<_Types...>::_Call(_STD declval<_Types>()...). See:

STL/stl/inc/type_traits

Lines 1594 to 1603 in 19067f6

	template <class _Callable, class... _Types> \
	CONSTEXPR auto _CONCAT(NAME_PREFIX, invoke)(_Callable && _Obj, _Types && ... _Args) noexcept( \
	noexcept(_CONCAT(NAME_PREFIX, _Invoker) < _Callable, \
	_Types... > ::_Call(_STD forward<_Callable>(_Obj), _STD forward<_Types>(_Args)...))) \
	->decltype(_CONCAT(NAME_PREFIX, _Invoker) < _Callable, \
	_Types... > ::_Call( \
	_STD forward<_Callable>(_Obj), _STD forward<_Types>(_Args)...)) { /* INVOKE a callable object */ \
	return _CONCAT(NAME_PREFIX, _Invoker)<_Callable, _Types...>::_Call( \
	_STD forward<_Callable>(_Obj), _STD forward<_Types>(_Args)...); \
	}

(which is difficult to read due to macro machinery; we're waiting for the compiler to implement a Core Language issue resolution, after which we'll be able to remove that macro and possibly simplify the code further).

What's happening here is that the function template invoke() is being implemented by calling a static member function _Call of a struct template _Invoker. This is what performs the template metaprogramming of inspecting the callable type and argument types, determining what kind of invocation expression to use (e.g. lambdas need to be called with parentheses, but pointers to member functions need to be called with syntax like (obj.*pmf)(args)).

Regarding pair, I was trying to clarify how variadic template pack expansion works, but I probably just made things more confusing; my apologies. pair is not actually involved in this issue.

By the way can i use https://godbolt.org/ in order to check if I made right corrections?

Hmm, I think that would be difficult, since this isn't a standalone snippet of code - it's the entire stack of machinery powering invoke() and its related type traits. It would probably be easier to write a small command-line test case for is_invocable, is_nothrow_invocable, is_invocable_r, and is_nothrow_invokable_r, verifying that it compiles with the current <functional> header, and then seeing if it compiles with your updated <functional> header. In this case, as the change is for improving compiler throughput (build speed), the goal is to simply keep the code compiling correctly (measuring the performance difference is difficult and we'll ask the compiler team to do that).

We have an extensive test suite for this <functional> machinery but we're still working on writing the test harness so we can put it on GitHub; this will probably not be available until January.