> BTW, I've just used the file `bash.1' version 2.05 from the linuxjm > project (with 217kByte it is about 30 times larger than `gprof.1'), > and profiling shows a completely different hot spot: > > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 43.14 0.22 0.22 78453 0.00 0.00 > unicode_decompose_ptable::lookup > 5.88 0.25 0.03 695361 0.00 0.00 token::next > 5.88 0.28 0.03 9941 0.00 0.00 file_iterator::fill > 3.92 0.30 0.02 202744 0.00 0.00 tfont::get_width > 3.92 0.32 0.02 108869 0.00 0.00 read_long_escape_name > ...
I've a bit experimented and tried the `improved' hash function given in http://www.haible.de/bruno/hashfunc.html However, this increases the hash collisions enormously, making the program slower by a large amount. It seems that I had to manually taylor a good hash function, but I fear that I'm not talented (and interested) enough to do so... Instead, I tried this patch --- ptable.h.old 2010-12-21 13:37:21.000000000 +0100 +++ ptable.h 2010-12-21 13:41:44.000000000 +0100 @@ -86,7 +86,7 @@ unsigned size; \ unsigned used; \ enum { \ - FULL_NUM = 3, \ + FULL_NUM = 1, \ FULL_DEN = 4, \ INITIAL_SIZE = 17 \ }; \ to reduce the filling of the hash table, increasing the number of empty slots by a large amount, and now I get this: % cumulative self self total time seconds seconds calls ms/call ms/call name 11.11 0.04 0.04 336788 0.00 0.00 hunits::hunits 8.33 0.07 0.03 825834 0.00 0.00 get_copy 8.33 0.10 0.03 695361 0.00 0.00 token::next 8.33 0.13 0.03 300089 0.00 0.00 check_unicode_name 5.56 0.15 0.02 290504 0.00 0.00 symbol::symbol 5.56 0.17 0.02 78453 0.00 0.00 unicode_decompose_ptable::lookup According to valgrind, while testing the Japanese `bash.1' man page, the additional amount of allocated memory is less than 200kByte; I think this increase of memory is a neglegible today... Note that the stuff in ptable.h is not used for the normal groff symbol dictionary lookup and the like. Opinions, please. Werner
