From: Will C. <wc...@re...> - 2003-03-21 21:42:49
Attachments:
oprofile-0.5.1-getc.patch
|
I have been running oprofiled with the --separate=library option. I noticed that there were a lot of samples for getc() in /lib/libc-2.3.2.so associated with oprofiled. Looking throught the code I found that op_get_line() in libutil/op_fileio.c is using fgetc(). This incurs a function call for each character read in. I generated a version that replaced the fgetc() with a getc() to reduce some of the overhead. Is there any particular reason to keep this as a fgetc()? 2003-03-21 Will Cohen <wc...@re...> * libutil/op_fileio.c (op_get_line): Use lower cost getc(). -Will |
From: Philippe E. <ph...@wa...> - 2003-03-21 23:07:15
|
Will Cohen wrote: > I have been running oprofiled with the --separate=library option. I > noticed that there were a lot of samples for getc() in > /lib/libc-2.3.2.so associated with oprofiled. Looking throught the code > I found that op_get_line() in libutil/op_fileio.c is using fgetc(). This > incurs a function call for each character read in. I generated a version > that replaced the fgetc() with a getc() to reduce some of the overhead. > Is there any particular reason to keep this as a fgetc()? Apply it please but rather to avoid someone think it's an optimization and try to re-submit it. stdio.h #define getc(_fp) _IO_getc (_fp) $ nm /lib/libc.so.6 | grep getc 00068594 T _IO_getc ... 00068594 W fgetc so both getc and fgetc use the same definition (getc macro has been changed to a call to fgetc implementation when locking was added to libc stream iirc) note ansi don't require getc to be a macro, it just say than getc can be a macro (traditionally it's always a macro) fgetc_unlocked will optimize code but I prefer to not use such non-standard things. regards, Phil |