From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: jtc@redback.com Cc: Jim Blandy , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [RFA] Revised C++ ABI abstraction patches Date: Thu, 15 Mar 2001 12:36:00 -0000 Message-id: References: <200103151850.KAA30796@bosch.cygnus.com> <5mae6mu8pc.fsf@jtc.redback.com> X-SW-Source: 2001-03/msg00248.html I was being thoroughly tongue-in-cheek. But the joke is made a bit bitter by stuff like partial-stab.h, where someone put 25k of code in a header file, which gets #included into two different .c files, to save function call overhead. Good call. When you set a breakpoint in partial-stab.h, you have no idea which .c file it's going into. The best way to set a breakpoint in there is to step to the place you want, and then do `break *$pc'. (Who's the maintainer of that code, anyway? ... Oh.) jtc@redback.com (J.T. Conklin) writes: > >>>>> "Jim" == Jim Blandy writes: > Jim> And besides, function calls are so slow. Remember, GDB's performance > Jim> matters a lot --- it's used to debug real-time operating systems! > Jim> :( > > I don't know whether you're being facetious, but IMHO avoiding > function call overhead is not a good argument for making a piece of > code a macro instead of a function. I've seen many circumstances > where macros (or inlined functions) decrease the overall performance > of a system because the added code results in i-cache thrashing. > > I think we should be addressing performance problems that are the > result of poor algorithms rather than spending any time bothering > with microoptimizations. Hear, hear.