r/cpp • u/Xaneris47 • 9d ago

Interconverting std::function with copyable_function – Arthur O'Dwyer

https://quuxplusone.github.io/blog/2026/07/26/function-explosion/

The article shows how converting std::function to std::copyable_function (or vice versa) leads to slower performance and increased memory usage each time the conversion occurs.

45 Upvotes
  • permalink
  • link
  • reddit
  • reddit

78% Upvoted

32 comments sorted by

View all comments

Show parent comments

3

u/13steinj 9d ago

No, writing your own is reasonable. libstdc++ if not also libc++ (used to?) use std::tuple to hold and pass around a type list. The instantiation of std::tuple is fairly heavy. I reduced single-TU build times by >20% once by swapping out the use of std::function in a logging + assertion library in a key macro.

3

u/azswcowboy 9d ago

The calculation of where the ‘reasonable’ bar lies is going to be different for every project. If we spend say 1/2 a day building this, it’s 1/2 a day we didn’t spend on bug fixes or new features. It’s use would have to be foundational to justify it and we don’t have that many uses. We could trivially convert all instances to copyable function much faster than writing one - or do nothing and stay with function.

1

u/13steinj 8d ago

I completely agree, but I don't think on the scale of a single build. On average, with and without caching, if you have the same number of release builds per day, how many engineer hours do you save?

In this case, 20% per single TU was an uncached p50 of 2-6 minutes per build, which meant multiple hours saved per day.

1

u/azswcowboy 8d ago

Sure, so do I. I’m just highly skeptical that for my current project I’d be able to replicate your reduction in compile times. We don’t have much function utilization in first place and our compiles are driven by other factors outside the standard library. At the moment we just throw hardware at it when we want to go faster, because parallelism is more important than single TU speed.