Hi Marc, On Wed, Jun 29, 2016 at 03:37:23PM +0200, Marc Lehmann wrote: > On Wed, Jun 29, 2016 at 07:09:00PM +0800, Fengguang Wu > <[email protected]> wrote: > > > And do notice slightly increased total time: > > Hmm, that looks somewhat inconclusive to me. Time for independent > verification: > > I did some tests by printing fully random, or the same 5/50/500 bg colour > change followed by "some words here", repeatedly. the test was effectively: > > time ./rxvt -e sh -c 'cat /tmp/x; sleep 1' > > http://ue.tst.eu/97ddec618dd0f436da3478fa6619bfdf.txt > > The first test was done twice with two different binaries, to get a feeling > for the variance. > > It seems hashing is detrimental to all cases, very much so in the fully > random test (where this is expected), but also slightly for the case where > it should trigger a lot (5 and 50 different colours).
5/50 falls into the below case (1). 500 is close to the below case (3). > Possibly things will be different when the cache is colder (either > direction), but as it seems, hashing does not particularly help. > > So we decided to go withoiut hashing at all. Agreed. Thanks for the more solid testing! Let me try some case studies: case 1 -- light use of 24-bit colors (most typical daily case) There will be mostly (rgb24_color[idx] == color) hits and the rgb24_index[] hash adds nothing but overheads. case 2 -- light use of 24-bit colors after changing many color schemes (less typical daily case) There will be little (rgb24_color[idx] == color) hits and the rgb24_index[] hash will help reduce the search cost case 3 -- randomly cycle through more colors than the cube (testing, not likely in daily use) There could be too frequent color updates and rgb24_index[] can hardly play enough "caching" role before being updated. case 4 -- clustered cycle through more colors than the cube (the below image test) There will be enough hash hits to show the benefit of rgb24_index[] img.sh URL: 'https://git.gnome.org/browse/vte/plain/perf/img.sh?h=vte-0-36' img.sh /usr/share/backgrounds/gnome/FootFall.png 0.93s user 0.10s system 121% cpu 0.849 total img.sh /usr/share/backgrounds/gnome/FootFall.png 1.00s user 0.14s system 115% cpu 0.988 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.92s user 0.13s system 118% cpu 0.886 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.93s user 0.11s system 122% cpu 0.851 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.82s user 0.13s system 118% cpu 0.796 total ============================================================================================== with hash 0.920 0.122 118.800 0.874 img.sh /usr/share/backgrounds/gnome/FootFall.png 0.93s user 0.11s system 121% cpu 0.854 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.92s user 0.16s system 116% cpu 0.927 total img.sh /usr/share/backgrounds/gnome/FootFall.png 1.00s user 0.12s system 114% cpu 0.976 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.91s user 0.14s system 122% cpu 0.851 total img.sh /usr/share/backgrounds/gnome/FootFall.png 0.91s user 0.14s system 122% cpu 0.854 total ============================================================================================== w/o hash 0.934 0.134 119.000 0.892 Since the hash hurts the most typical case (1), better go without it. > Patch will be applied very soon btw., thanks again. Thanks! Regards, Fengguang _______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
