Thread: A question about performance and free()

There isn't anything yet to suggest that a lookup table is remotely useful here. The question raised is about efficiency:

Would it be more efficient to calculate all the a's first in som other loop, and simply accessing them in memory?

How can one even entertain the notion of introducing a lookup table when there's a glaringly obvious optimisation that makes it redundant immediately?! If I can see it then perhaps the compiler can too. The whole question of the code efficiency hinges directly on what is stopping the compiler from making this optimisation itself. That's where the answer to this efficiency question lies. It's not as important whether it actually does that optimisation or not, it's more about how the presence of such other code completely alters the efficiency of this entire snippet. The code posted must be as close to the real code as possible, and the mock example we have so far just doesn't tell half of the real story.

As for number 2, one way or another it just knows, and it is likely different from one compiler, CRT, or OS to another. If you can imagine a way for the CRT to know that, then there's a reasonable chance that you're not far off for how at least one system does it.

Originally Posted by The Physicist

Is it possible to tell the compiler, for debugging purposes, to spread out all the malloc'ed memory, thus forcing the program to segfault when accidently writing to a value that is beyond the end of the array? Or is there an other clever way to get the compiler to notice whenever you write beyond the end of an array? I'm using gcc, but I assume that the answer will be the same for all the most common compilers.

There is no COMPILER option to do this, that I am aware of. However, your idea is very insightful, and something that I have implemented manually in the past.

I call it "memscatter," and the idea is to allocate thousands of blocks of memory of random sizes at program startup, then randomly select some fraction of these blocks to free up. The resulting heap fragmentation changes the behavior of the program and makes it easier to shake out memory corruption bugs (i.e. it crashes sooner and therefore makes it easier to find the problem). However, this is a last resort technique which is useful only when no other option is available.

You may want to investigate a tool called "electric fence" which overrides the default memory allocator to align all allocations to the beginning, or end, of a VM page, with invalid pages before and after the allocation. If the code goes outside the array, it will segfault and you can immediately see the bug.

Also, tools like Valgrind, which execute your program in a virtual machine and monitor memory accesses at the level of single bits, can easily find such bugs.

At work, we use Purify, which is an on-line instrumenter which changes the code in magical ways to automatically detect such problems.

Yeah, valgrind is cool, it catches leaks and access errors and is dead simple to use. At least to do that much -- I haven't tried to do anything else with it.

Be nice if it reported errors by line, like a debugger, instead of by function tho. Actually a debugger that integrated something like valgrind would be pretty nice.

==2419== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==2419== malloc/free: in use at exit: 0 bytes in 0 blocks.
==2419== malloc/free: 5,999,977 allocs, 5,999,977 frees, 155,999,984 bytes allocated.
==2419== For counts of detected errors, rerun with: -v
==2419== All heap blocks were freed -- no leaks are possible.

Joy....

Originally Posted by MK27

Be nice if it reported errors by line, like a debugger, instead of by function tho. Actually a debugger that integrated something like valgrind would be pretty nice.

It does, but you have to build your program in debug mode. Unless you mean something else.

Originally Posted by brewbuck

It does, but you have to build your program in debug mode. Unless you mean something else.

By golly yer right!

==2483== Invalid read of size 8
==2483== at 0x401E19: cleartree (bayer-demo.c:78)
==2483== by 0x401F5D: main (bayer-demo.c:132)
==2483== Address 0x519d198 is 8 bytes inside a block of size 48 free'd
==2483== at 0x4C2509F: free (vg_replace_malloc.c:323)
==2483== by 0x401E14: cleartree (bayer-demo.c:77)
==2483== by 0x401F5D: main (bayer-demo.c:132)