What fun!! I think the saving might decrease when the function has more
duration. Then maybe footprint might matter more.
Going back to the suggestion of a kind of filter on the result of malloc, it
might not be necessary to force inline but allow it. As janI suggests, the
definition of the filter can be in a platform file and therefore have
platform-specific provisions.
I that means it needs to be defined fully in a header file to get the desired
effect at the point of call. That's doable. The StdC library has tons of
those arrangements.
Also, in this form, which I did not lay out, I think this might optimize well:
01 void* CheckedAlloc(size_t n)
02 { void* p = malloc(n);
03 if (p == NULL)
04 AllocFailure();
05 return p;
06 }
(Your { ... } placement may vary [<). The project uses K&R form, not what I
show here.)
Here AllocFailure() is a void procedure and although it never returns, the
compiler doesn't have to know that. Of course ALlocFailure() be completely
defined in the platform-specific folder, too.
I wonder, would it work better to have AllocFailure defined as if it returned a
void*
And make line 4 above be
04 return AllocFailure();
Now we're really squeezing on the bits.
It's going to be fun with you playing around here. Made my day.
- Dennis
-----Original Message-----
From: Gabriela Gibson [mailto:[email protected]]
Sent: Wednesday, February 18, 2015 17:23
To: [email protected]; [email protected]
Subject: Re: Checking malloc success and adding perror()
Hi,
Dennis asked: how much time is saved with an inline function? I needed to
know! :-)
Answer:
A small amount (on my trusty old 32-bit lappie) using gcc over 100000000
iterations, then again, ~1/4 time saving is not to be sneezed at.
Output:
Time spent on regular function: 0.667472
Time spent on inline function: 0.424117
[[
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
#include <time.h>
// Note: forcing inline may not always work, and I'm not sure how portable
this is.
//
// functioncall-comparison.c:12:37: warning: always_inline function might
not be inlinable [-Wattributes]
// __attribute__((always_inline)) void my_function(void)
void my_function_regular(void)
{
3.14 + 1;
}
__attribute__((always_inline)) void my_function(void)
{
3.14 + 1;
}
int main (int argc, char *argv[])
{
clock_t begin, end;
double time_spent;
begin = clock();
for (size_t i = 0; i < 100000000; i++)
my_function_regular();
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
printf("Time spent on regular function: \t %f\n",time_spent);
begin = clock();
for (size_t i = 0; i < 100000000; i++)
my_function();
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
printf("Time spent on inline function: \t %f\n",time_spent);
exit(EXIT_SUCCESS);
}
]]
On Thu, Feb 19, 2015 at 12:33 AM, Dennis E. Hamilton <
[email protected]> wrote:
> If I might offer a small build on Jan's idea.
>
> Define a function, null-check, perhaps an in-line one, that does something
> like
>
> void* CheckAlloc(void* p)
> {if (p == NULL)
> AllocFailure();
> return p;
> }
>
> with all other repetitive stuff in AllocFailure().
>
> Invoke CheckAlloc with a malloc( ) call as its parameter, and put its
> result
> wherever the non-null pointer is needed, casted as necessary.
>
> You could even make a CheckedMalloc and even put the malloc call inside,
> passing
> in the size_t. I am not certain how much that saves though.
>
> Experiment?
>
> - Dennis
>
>
> -----Original Message-----
> From: jan i [mailto:[email protected]]
> Sent: Wednesday, February 18, 2015 14:00
> To: [email protected]
> Subject: Re: Checking malloc success and adding perror()
>
> Hi
>
> First thanks for your ideas, they are very welcome.
>
>
> On 18 February 2015 at 22:19, Gabriela Gibson <[email protected]>
> wrote:
>
> > Hi,
> >
> > Reading through the source, I see that a lot of mallocs() do not have a
> >
> > [[
> > if(foo == NULL) {
> > perror("Foo: Out of memory.\n");
> > return _exit(EXIT_FAILURE);
> > }
> > ]]
> >
> > check.
> >
> > I can add those if you like.
> >
>
> It get a big +1 from me.
>
> BUT if you do it generally I would prefer we make a central function in
> e.g. platform
>
> void DFextBailout(<text>)
> {
> perror(...)
> exit(EXIT_FAILURE)
> }
>
> That way we only need to change in one place if we e.g. one day want a
> special logging.
>
> I would NOT make a assert() like macro that includes the condition.
>
> Please wait for Peter to comment, he might remember why there was no tests
> in the first place.
>
> rgds
> jan i.
>
>
> > G
> > --
> > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
> >
>
>
--
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
