Bill Pringlemeir wrote: > Ok. I guess you got the routing.c and the one line in props.c as > well?
There were even two lines - fixed. > It is much easier to be a critic than an artist. Well, thanks a lot for double-checking the recent commits. > I especially like > the removal of the all the strdups and the GCC format checking. The > strdup change should reduce the allocation load of GTKG. I didn't > even know about the GCC format checking, so I am glad I looked at the > changes. The integer assert checks were also a very good change. GCC's format string checking is surely one of the best inventions since sliced bread. IIRC, I *always* found one bug or another when I added it to any code. Don't forget to add -Wformat=2 to your CFLAGS to take full advantage of it. > Maybe I can ask what the heck the "fake name" is about? I have seen > GTKG clients with a "!gtk-gnutella" user agent. There are some routines which check whether the User-Agent is faked or not - mainly because we don't want to debug problems which do not even exist in GTKG but in another software which just claims to be GTKG. However, the check might fail for non-faking servents under certain circumstances so you have to use a grain of salt. > Also, would there be a restriction against using the OpenSSL assembler > routines for the SHA calcs? Do you mean by copying the code? Well, the current code was copied from the relevant RFC, so if the licenses are compatible and the OpenSSL code is better, there isn't really a reason to not use it. > Or is there a rule against putting assembler into GTKG? I don't really think using assembler gives necessarily faster code. It's pretty hard to keep track of different CPU models and revisions so that an assembler variant is sometimes (or maybe even often) slower than a good plain C variant. GCC has some extensions WRT cache directives which can give a reasonable speed up as well. Also, simple code reordering can make a huge difference. I've done this a while ago to optimize the RGB -> YUV conversion for an emulator where I didn't want to use any assembler (because of the reasons above and also because I haven't seriously used any real assembler for years as I consider this masochism and find the x86-centric view of some people quite obscene now). Anyway, I assume that there are fallbacks for architectures for which no assembler code is provided. > Would it be worthwhile to benchmark some hashes to see if it was a > worthwhile pursuit? I think there are benchmarks available for several libraries so we probably simply use those. If you think that the hashing is too slow then you might miss the fact that it's intentionally throttled so that it doesn't use too much CPU and I/O which could turn GTKG into a CPU hog for hours if you share a lot of files and/or don't have a really fast CPU. Maybe this could or should be configurable if you really want to index you library as fast as possible. Christian
pgp3NvBmpNPIJ.pgp
Description: PGP signature
