Hi,
I am allocating memory using malloc() and then I am filling the aloocated memory with "0" using memset().
The combination of malloc() and memset() are being called many times in my project.
After adding memset() function affecting my project's performance. So I am searching for the alternative for the memset().
I have used calloc(), instead of combination of malloc and memset as a work around.
But I need an exact faster solution for my problem.
I have used calloc(), instead of combination of malloc and memset as a work around.
calloc is the functional equivalent of malloc + memset. It might be faster due to the potential for standard library optimization over hand rolled code, but probably not enough to make a big difference.
Have you considered
If allocating and initializing dynamic memory is a significant part of your program's overall execution time, you may want to reconsider your design.
My reason for saying this is that if initialization is significant, it suggests that you're not doing much else with the memory aside from initializing it. In that case, why are you using it at all? Perhaps you can answer this question in a way that provides an alternative to the initialization.
Mr. Koenig is someone to pay attention to. If you are spending too much time/cycles in memory allocation/initialization, then the usual solution is to cache the memory so it can be reused without reallocating. In truth, memory management is one of the gnarlier problems that complex and long running applications have to resolve. To determine what are the best approaches to take requires an in-depth analysis and understanding of your code, and its trade-offs with regard to system resource utilization.
So, let's say that analysis indicates that your program uses, and frees, 512 byte segments (it can be any size, or combinations of sizes), frequently, yet uses a maximum of 1000 of these at any time (give or take). Then you can build a specialty initiator, allocator, and releaser that your code can use. When the program starts, it automatically allocates and clears 1000 of these 512 byte segments with the initiator. When some code needs a 512 byte segment, it requests it from the allocator which will take a buffer off its free list, add it to the used list, and give it to the requester. When it is done with it, the program calls the releaser which takes it off the used list and adds it back to the free list. If you want, you can clear the buffer in the releaser at that time, but that may not be necessary. FWIW, this also reduces system memory fragmentation and overall utilization that occurs with the normal malloc/free usage.
What are you allocating the memory for, and why do you need to ensure that it is cleared/populated?
The answers posted in this thread are all very good. Still, here is a practical answer to your question.
This is a bad way to clear memory for an enormous string:
char *EnormousString;
EnormousString = calloc(999999999999999);It works good for small strings, but if its a precious cog in your main loop, it wont do you any favors. Here is a much better way to do the same job:
char *EnormousString;
EnormousString = malloc(999999999999999);
EnormousString[0] = '\0';That method is many times faster than the first one. In this case the only real job for the computer is to find a contiguous slice of RAM with 999999999999999 bytes.
Of course, the second method doesn't actually clear the memory, which is why it appears to be faster.
Of course, the second method doesn't actually clear the memory, which is why it appears to be faster.
Well, as you explained earlier...
why are you using it at all
In my example, I "cleared a string". The very concept of clearing a string is to empty it, and the way it is done in C is putting a "NULL character" at the beginning of it. Why would anyone want to nullify the entire unused string? I could understand emptying the memory of an array of integers for some matrix operation, or other complex structures, but a string is among the most basic examples of memory that has no reason to ever be cleared when allocated. This is why I felt it was the best example to use to illustrate the concept of "why are you using it at all".
Some people understand things better with words, and others understand things better with pictures.
nullifying the entire buffer means that appending any textual data will result it a properly terminated string.
In my example, I "cleared a string". The very concept of clearing a string is to empty it, and the way it is done in C is putting a "NULL character" at the beginning of it.
That's your opinion. Neither of us knows whether it is also the original poster's opinion. What we do know is that the original poster asked for a faster way to do what memset does, and putting a null character at the beginning of an array is different from what memset does.
That's your opinion. Neither of us knows whether it is also the original poster's opinion. What we do know is that the original poster asked for a faster way to do what memset does, and putting a null character at the beginning of an array is different from what memset does.
Its not an opinion, its a perspective. And that's what everyone's very intelligent answers implied, which is that the perspective of the use of memset must change, not to find a faster memset. Therefore, as a practical way to illustrate that concept of viewing the problem in a different light, "clearing a string" is an excellent example.
Perhaps it would be a good time to point out that the OP never said anything about allocating the memory for strings, specifically. We have no way to know, from the given information, what the allocated memory is being used for, hence the questions about purpose.
Given that the OP has not replied to any of the follow-up messages, however, it is very possible that this entire discussion is moot.
Perhaps it would be a good time to point out that the OP never said anything about allocating the memory for strings, specifically. We have no way to know, from the given information, what the allocated memory is being used for, hence the questions about purpose.
Given that the OP has not replied to any of the follow-up messages, however, it is very possible that this entire discussion is moot.
As I said, its a practical example of a concept behind our answers, not an answer to a question.
I don't really care if the discussion is moot. I found this forum thanks to a moot discussion on a topic answered years ago. And I have learned many things on this forum and I am very thankful for it. As much as I like helping people, everything I write is viewed by a much larger audience, and to that end I try to be as general as I can with my answers so they may apply to others in his situation.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.