Hacker News new | past | comments | ask | show | jobs | submit login

You know what it does:

    The calloc() function contiguously allocates enough
    space for count objects that are size bytes of memory
    each and returns a pointer to the allocated memory.
    The allocated memory is filled with bytes of value zero.
You should not care how it does it.

Spoken like someone who does not ship fast software!

There's a saying that is often misused, but applies here: "premature optimization is a root of all evil"

You first write your code using standard system functions, using the right calls for what you're doing. If after that performance of the code is bad because of calloc() only then you roll out your own implementation (most likely in assembly), and accept that in the future your code might not work well, because something in your OS has changed since you wrote your code.

It's not always the best way to write software. If you're writing a program that's supposed to work in real(ish) time then it's good to take performance into consideration early on, otherwise you'll end up rearchitecting your program later. It's not necessarily about a number of cycles each operation takes, but rather about memory layout of your data. I guess it's a matter of experience: if you expect something to be a bottle neck (because it was a bottleneck in a similar application you've written in the past) then maybe you should just write it properly the first time round?

That's why I mean when I said that the saying is abused. Some people think that choosing the right algorithm is premature optimization. It is not.

Choosing whether to use malloc vs calloc is not an architectural change though, and in fact it is very easy to replace one with the other, but if you use the right call for right use case, then you will benefit from optimizations that the OS provides, and often you might not even be able to achieve them from user space.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact