Is DispatcherQueue::GetForCurrentThread() expensive?

[amtopel]

Is it okay to call winrt::Microsoft::UI::Dispatching::DispatcherQueue::GetForCurrentThread() on an as-needed basis?
Or is it better to store the returned DispatcherQueue in a variable? In other words, does GetForCurrentThread() already do some caching?

I've looked at the source code, but like a lot of C++/WinRT, I can't really tell what it's doing:

inline auto DispatcherQueue::GetForCurrentThread()
{
    return impl::call_factory_cast<winrt::Microsoft::UI::Dispatching::DispatcherQueue(*)(IDispatcherQueueStatics const&), DispatcherQueue, IDispatcherQueueStatics>([](IDispatcherQueueStatics const& f) { return f.GetForCurrentThread(); });
}

Thanks for any info.

[castorix]

MS can call it in constructors in their samples, like :

microsoft-ui-xaml/dev/inc/DispatcherHelper.h

Line 15 in 33541da

dispatcherQueue = winrt::Windows::System::DispatcherQueue::GetForCurrentThread();

MainWindow.xaml.cpp#L22

or global class variables :

XamlAmbientLight.cpp

[DarranRowe]

On the ABI level, it would be a series of calls including RoGetActivationFactory to get the IDispatcherQueueStatics interface, followed by IDispatcherQueueStatics::GetForCurrentThread.
However, digging into the C++/WinRT code a little, call_factory_cast is using a cache to keep the IDispatcherQueueStatics instance around. This would cut out the RoGetActivationFactory call, which is the worst part of the GetForCurrentThread call. This just leaves a pretty quick lookup of the cached factory followed by the GetForCurrentThread call, which is a virtual member function.
So, it is more expensive than just caching the DispatcherQueue itself, but if you are doing infrequent calls to get the DispatcherQueue then the time taken will be lost completely in the total runtime of the application.

[amtopel]

Thank you both for the responses.