<stacktrace>: Should we reduce allocations in operator<< and formatter?

[frederick-vs-ja]

It seems that we can avoid allocating whole strings in the operator<<s by designing suitable filling functions.

(_Os should be locked and unlocked directly in the operator<<s.)

STL/stl/inc/stacktrace

Lines 332 to 340 in 5762e6b

	_EXPORT_STD template <int = 0>
	ostream& operator<<(ostream& _Os, const stacktrace_entry& _Fx) {
	return _Os << _STD to_string(_Fx);
	}
	_EXPORT_STD template <class _Alloc>
	ostream& operator<<(ostream& _Os, const basic_stacktrace<_Alloc>& _St) {
	return _Os << _STD to_string(_St);
	}

But this approach probably needs more xsputn calls, as the underlying buffer can have various types. Do we want this?

---

It seems to me that such optimization in formatter specializations would be less controversial.

[StephanTLavavej]

But this approach probably needs more xsputn calls, as the underlying buffer can have various types. Do we want this?

My heuristic without profiling is "TOUCHING IOSTREAMS IS DOOM", but it's hard to argue with benchmark results.

I would want to see the code complexity increase versus the perf speedup in order to evaluate whether it's worthwhile.

[AlexGuteniev]

Since the formatter is easier part, I guess it can be attempted first, alone. Then it will be seen better if dealing with streams is worth doing.

I'm also asking if separately compiled code change is needed. Changing that is another level of complexity.

[frederick-vs-ja]

I'm also asking if separately compiled code change is needed. Changing that is another level of complexity.

I think it's possible to only change the header, because filling callback functions are controlled in the header and the type-erased interface seems sufficient.