Newsgroups: comp.lang.c Path: utzoo!sq!msb From: msb@sq.sq.com (Mark Brader) Subject: Re: Just a minor new twist on free() Message-ID: <1990Oct9.000713.13417@sq.sq.com> Summary: Measure, don't assume Organization: SoftQuad Inc., Toronto, Canada References: <1990Oct02.132313.6659@virtech.uucp> Date: Tue, 9 Oct 90 00:07:13 GMT Lines: 30 > While your simple case might indeed not be much of a performance hit, > what about something like: > #define ARRAY_LEN 10000 > char *array[ARRAY_LEN], **ap; > int i; > for (ap = array, i = 0; i < ARRAY_LEN; ++i, ++ap) > { > if (*ap != NULL) > free(*ap); > } /* Syntax and type errors corrected - msb */ That's probably still not a significant performance hit. On the machine I'm typing this on, it appears to cost somewhat under 0.1 second of CPU. Even on a slower machine, a real-life program would be *doing* something with those ten thousand malloc()ed objects, and the cost of ten thousand compares and branches would probably be negligible in comparison. Or to put it another way: if you need to execute "if (p) free (p);" so many times that the "if (p)" tests contribute significantly to the cost of the program, then you probably need to reorganize the program. -- Mark Brader "The last 10% of the performance sought contributes Toronto one-third of the cost and two-thirds of the problems." utzoo!sq!msb, msb@sq.com -- Norm Augustine This article is in the public domain.