So in each iteration, this is what happens.

ptr = malloc
process(ptr)
free(ptr)

I am wondering doing frequent malloc and free is ok? Will this
fragment the memory?

That said, the first response was correct in that it's not likely to
make much of a difference in this quite simple case. In general though,
I would avoid unnecessary repeated allocations and frees in a tight
loop.

(untested, no error checking)

    #define BUFFSZ 20  /* any size you like, 2 will do */
    #define MEM_INCREMENT 2 /* unless you have a good reason use 2 */

    void *tempalloc(int nbytes) {
       static void *p=malloc(BUFFSZ);
       static int currbufsize = BUFFSZ;
      

      while ( nbytes > currbufsize)  {
          curbuffsize = currbufsize*MEM_INCREMENT;
          p==remlloc(p,currbuufsize);
      }

      return p;

Depending on what sizes you malloc, and what order you do so, and what other
memory allocating/freeing might be going on, the answer is a definite "maybe".

I might suggest a tweak to your method, however.

Keep track of the size you allocated.  Then, rather than unconditionally
freeing it and allocating a new chunk, check the new size that you need.  If
the current allocation is at least that large, use the current allocation.
Otherwise, free/malloc, and keep track of the new size.  Then, after the
loop is finished, free the memory once and for all.

And, if you're feeling adventurous, start with a block of memory that
"should" be sufficient for "most" scenarios.

Section 8.7 of the 1978 edition of The C Programming Language
describes a storage allocator system in which the freeing function,
merges the freed regions of memory, for the allocating function to use.

http://codepad.org/kTdySzAe
______________________________________________________________
#include <stdio.h>
#include <stdlib.h>

#define ITERS 128U

#define RAND() ((size_t)rand())

#define STRING_MAX_SIZE 64U

#define STRING_ALPHABET "ABCDEFGHIJKLMNOPQRSTUVWXYZ"

#define STRING_ALPHABET_GET() \
    STRING_ALPHABET[RAND() % (sizeof(STRING_ALPHABET) - 1)]

char*
string_populate(
    char* string,
    size_t* psize
){
    size_t i;
    size_t size = RAND() % STRING_MAX_SIZE;
    *psize = size;

    string[size] = '\0';

    for (i = 0; i < size; ++i)
    {
        string[i] = STRING_ALPHABET_GET();
    }

    return string;

    for (i = 0; i < size; ++i)
    {
        putchar(string[i]);
    }

    puts("\n_______________________________________________\n");

    for (i = 0; i < ITERS; ++i)
    {
        size_t size;
        char* string = string_populate(buffer, &size);
        string_process(string, size);
    }

    puts("\n\n___________________________________________\n"
         "The program has completed.\n");

    getchar();

    return 0;

E.g.:

        for (n = n0; n <= n1; n++) {
                void *p = malloc(n);
                void *q = malloc(1);
                ...
                free(p);
        }

Each new allocation will be 1 byte too large to fit into the space
for the previous allocation. Some of them will fit due to the previous
allocation having been oversized, but they can't all fit.

For programs like you describe, it might be less time-consuming to
keep re-using the single chunk of memory as long as it's big enough,
and realloc() it larger when needed.

Here's an example of (rather horribly) fragmenting memory:

You have only 1000TB of memory for string data.  You allocate
10,000,000,000,000 strings averaging 100 bytes each (including
malloc() bookkeeping overhead) and maybe ranging in size from 50-150
bytes.  (Perhaps these are DNA fragments from various species.)
This just about fills up the memory.  Now free() all but 10,000,000
of them, but which of the strings gets free()d and which gets kept
depends somewhat randomly on external data.  There is only about
0.001 TB of memory still allocated, but the strings are scattered
all over, so good luck trying to allocate 1TB of contiguous memory,
even though you've got 1,000 times that in free memory.

Oh, yes, malloc()/free() cannot move allocated memory unless there's
a sophisticated garbage collector that can track down all references
to memory in use, including in files.

Some allocators try to avoid fragmentation by taking large requests
from one pool, and tiny requests from another, perhaps with a whole
range of power-of-two-sized blocks.  That can be effective, but not
in the above case, since all of the strings were roughly the same
size.