logoalt Hacker News

CyberDildonicstoday at 8:18 PM1 replyview on HN

It has a single global mutex over alloc/free paths. It does syscalls underneath that lock (mmap)

Every default malloc implementation worked this way about 12 years ago. Making lots of small allocations, even from multiple threads then blaming the allocator is a losing strategy. An allocator is only going to be able to mitigate the damage to speed and interactivity.

The solution is and always has been to make larger allocations and use those efficiently.

They are just naive loops with nearly no optimization.

The compiler should be able to take something with good access patterns and make something fast, especially out of the basic C functions.

they are the backbone of vast amounts of code

Performance wise it's unlikely C string functions are actually the bottleneck in a program. Maybe for specific programs a naive memory copy function could benefit from AVX instructions.

Real programs have to often do things like allocate memory

"Have to" and "often" are debatable. Any allocations in a hot loop are the very first things that should be optimized away after profiling.


Replies

wakawaka28today at 8:23 PM

>Performance wise it's unlikely C string functions are actually the bottleneck in a program. Maybe for specific programs a naive memory copy function could benefit from AVX instructions.

Many programs use lots of strings. It tends to become a bottleneck. It also tends to be very difficult to improve because the strings are everywhere in that kind of program, and refactoring to eliminate them is either impossible or very risky.