I have a simple performance question. m/c/realloc all seem to take quite a bit of time when you use them over and over. For example, when I read in a file, I tend to realloc of char * to increment its size by one for every character. I was recently thinking however, that it may be smarter to realloc it by 25 or something, and keep a read character tally, which when it reaches 25 would realloc the char * again to make space for another 25. At the end of the code block, you simply realloc to the size of the string minus (25 - character tally). So if we had read 18 characters by the end, we have made space for an extra 7, so realloc it away. Do this make sense? Is it a better way of doing it than reallocing for every character? Does anyone else do this sort of thing, or have any other good ideas for m/c/realloc performance enhancement? Thanks -visage

Yes, that is a good idea, and if you find a good way to predict how much memory to set aside, it can save you a lot of time. In many cases even larger blocks of memory are set aside at once, sometimes using an amount predicted as the maximum the data could grow. Of course, if that maximum isn't set in stone, or if it's hard to predict, you'll have to come up with a more practical system.

does anyone know the cycles for each realloc?
what I am trying to say is that for example: does reallocing for 50 chars take longer than reallocing for 1? Is there a factor you can multiply by?

Most STL implementations' dynamic arrays reallocate by a factor of two each time. For instance, if you had a vector with 64 elements in it already, when you added the 65th element it would reallocate to 128 positions.

Can you access those even though virtually you haven't allocated for that space? So if I allocate for the 65th element, "virtually" I only have 65 spaces, but technically I have 128, right? Can I access up to 128, or will I get a memory error?

If you're talking about STL vectors, technically you can access the memory, but it has not been initialized (the constructor has not run) and really shouldn't be used for anything. There's nothing stopping an STL implementation from arbitrarily writing over the "unused" area with random memory.

Thank you very much sir.

Quote:Original post by visage
does anyone know the cycles for each realloc?
what I am trying to say is that for example: does reallocing for 50 chars take longer than reallocing for 1? Is there a factor you can multiply by?

The short version: It's hard to say, just assume that it's a lot, and try to minimize your usage of these functions.

The long version: The time taken by realloc()/malloc()/calloc() is highly variable and extremely implementation and usage dependent. One common implementation of the C runtime heap manager involves searching through what's effectively a linked list of available memory blocks. If an available block of appropriate size is found early, then it can return relatively quickly. If no avaiable memory block of appropriate size is found, it can take a really long time (cache misses and page faults on the memory being searched, followed by a kernel context switch as it request more memory from the operating system, and so on).

How much the relative size of the memory requested affects the time taken by the memory allocation would also be implemntation dependent, and often is non-intuitive. For example, a system based on a binary buddy suballocator can be faster on average when allocating large blocks than when allocating smaller blocks.