On Sunday 02 February 2003 11:35, Neal Richter wrote:
> very few of our
> inline functions end up getting inlined. I've done a fair bit of
> work with gprof and looking at what functions are actually inlined
> in the assembly. At least with -O2 I'm not seeing some of them
> making it.
What version of gcc are you using? I've just compiled using 3.1,
and it seems to be inlining. For example, the copy constructor gives
the output below, which clearly shows line 229 of htString.h being
inlined.
.align 2
.p2align 4,,15
.globl _ZN6StringC2ERKS_
.type _ZN6StringC2ERKS_,@function
_ZN6StringC2ERKS_:
.LFB7:
.loc 1 67 0
pushl %ebp
.LCFI34:
movl %esp, %ebp
.LCFI35:
pushl %ebx
.LCFI36:
pushl %edx
call .L31
.L31:
popl %ebx
addl $_GLOBAL_OFFSET_TABLE_+[.-.L31], %ebx
movl 8(%ebp), %edx
movl 12(%ebp), %ecx
.LBB10:
movl _ZTV6String@GOT(%ebx), %eax
addl $8, %eax
.loc 1 68 0
movl $0, 4(%edx)
.loc 1 67 0
movl %eax, (%edx)
.file 38 "htString.h"
.loc 38 229 0
.LBB11:
.LBB12:
movl 4(%ecx), %eax
.loc 1 68 0
.LBE12:
.LBE11:
movl $0, 8(%edx)
.loc 1 69 0
movl $0, 12(%edx)
.loc 38 229 0
testl %eax, %eax
jle .L25
pushl %eax
pushl %eax
movl 12(%ecx), %eax
pushl %eax
pushl %edx
.LCFI37:
call _ZN6String4copyEPKcii@PLT
addl $16, %esp
.loc 1 73 0
.L25:
.LBE10:
movl -4(%ebp), %ebx
movl %ebp, %esp
popl %ebp
ret
.LFE7:
.Lfe7:
.size _ZN6StringC2ERKS_,.Lfe7-_ZN6StringC2ERKS_
This isn't from DDD, but using the command
/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I../include
-DDEFAULT_CONFIG_FILE=\"/home/lha/devel/htdig/install//conf/htdig.conf\"
-I../include -I../htlib -I../htnet -I../htcommon
-I../htword -I../db -I../db
-I/usr/include -g -O2 -Wall -fno-rtti -fno-exceptions -S String.cc
which is what my makefile generates, but with '-c' replaced by '-S'.
> My next set of changes are going to be enhancements to WordDB, &
> WordKey.
These sound like good improvements. However when I do a dig of my
local computer, it seems rather disk bound, with CPU usage hovering
around 50%, of which a lot is system time. I haven't yet checked how
much of this is reading the input docs and how much is database
access, but my guess is that implementing your more compact database
format will give more bang for your development buck. It has the
added advantages that it uses less disk space, and that it speeds up
searching (assuming that is also disk bound). However, I am really
keen to get 3.2.0b5 out and I personally won't be working on
optimisations until then. Thoughts?
> I need to get more familiar with how gcc does some of these
> optimizations.. but at the same time I'm inclined not to rely on it
> too much.
Agreed. We should eliminate unnecessary function calls, but *some*
will still be needed, and we might as well get those inlined.
Cheers,
Lachlan
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/htdig-dev
