There are a few problems here. The first saying that anything is dramatically worse. The second is thinking that nothing can be changed. The third is thinking that there are lots of programs out there that spend all their time in C string functions yet nothing can be altered except for linking in a different standard library.

I can't tell you where, or show you code, or anything like that. Get used to it.

I didn't expect at any point that you to be able to back up what you are saying with examples.

Everything you've said is "It's NOT a problem because I'VE never seen it be a problem!"

That couldn't be further from the truth. I'm saying it isn't a problem because the problems are easily fixable and musl doesn't prevent them from being fixed.

You hallucinated a quote and made up something completely different in your head.

If you don't think string processing is a bottleneck, you should consider how many applications are document-based and string-based. Basically, it's a MAJORITY of applications in the world, and I'd put money on that.

You think these programs are bottlenecked by the C-string functions in their standard library? That's a bold claim. Why would a program completely dependent on strings even use C string functions in the first place? You have to scan to a newline to find the length, they work with ascii and they are known to be incredibly insecure. What you're saying doesn't make sense.

You clearly deny having experience with the stuff I'm talking about,

I deny that there are programs that can only be sped up by switching to a different C library and nothing else, since that's nonsense.

just not use MUSL if that's your problem.

People can do whatever they want, all I've ever said is that musl doesn't prevent anyone from making a fast program. That's it.

Saying you're inexperienced is not insulting,

I'll take your word for it because you seem extremely inexperienced at optimizing, especially if you think making fast software should include leaning on C strings and having memory allocation show up on your profiler.

This is youthful arrogance (I can only assume you're young; if not, you at least haven't matured in your career).

You can go for the insults and try to be patronizing again, I expect that as the last resort of someone frustrated that repeating their claim isn't taken as evidence. I explained a lot in detail about why musl isn't going to prevent anyone from writing fast software because I've done it over and over.

You seem to be saying that you can speed up legacy programs somewhat that weren't made well in the first place with a faster libc and I'm sure that's true, but it has nothing at all to do with the premise the musl prevents a program from being fast or even is much of a bump in the road.

The speed ups from a more optimized libc are percentage points shaved off the the times where you actually use it. Using better string functions, minimizing allocations and paying attention to memory access patterns are going to be order of magnitude changes. Minimizing allocations is going to be at least 7x on a single core, better memory access patterns are going to be 20x-25x.

You don't have any evidence or explanation that musl prevents someone from writing fast software, which is the title and the title is wrong.