On 07/20/2012 01:39 AM, Richard Guenther wrote: >> > I've not yet speed tested this, only completed bootstrap + test >> > runs for both x86_64 and ppc64. I've done sanity cross compiles >> > to alpha and mips (the only SWITCHABLE_TARGET). > It would be interesting to see startup-time effects of this patch (thus, > compile-time of an empty CU).
I've now done some speed testing on x86_64. Best I can figure, everything is within measurement error. I tried both standalone compilations of combine.ii and bootstraps. I had to loop executions of cc1[*] to even measure the startup time as requested, in which the only effect seems to be a narrowing of stddev. I did some gperf profiles of the combine.ii compilation. There, the cumulative time in raw_optab_handler just barely makes it to 0.01 sec with 76k invocations. So while we could make that unmeasurable with a minimal perfect hash, we probably wouldn't actually be able to notice its effect on compilation as a whole. So I guess we're down to theoretical improvement in memory usage and startup, and a real improvement in maintainability due to the consolidation of the places that must be modified to add or edit an optab. No other comments over the weekend, really? r~ [*]: #include <unistd.h> #include <sys/fcntl.h> #include <stdlib.h> int main(int ac, char **av) { int i, count = atoi(av[1] ? av[1] : "100"); close (0); close (1); open ("/dev/null", O_RDONLY); open ("/dev/null", O_WRONLY); for (i = 0; i < count; ++i) { int f = vfork(); if (f == -1) return 1; if (f == 0) { execl ("./cc1", "./cc1", "-quiet", "-o", "-", NULL); _exit (1); } wait(NULL); } return 0; } time loop 1000: NEW real user sys OLD real user sys 11.344 7.765 2.962 11.456 7.770 3.033 11.296 7.786 2.862 11.286 7.787 2.843 11.312 7.776 2.897 11.323 7.740 2.942 11.367 7.820 2.917 11.355 7.800 2.916 11.275 7.777 2.852 11.354 7.708 2.974 avg 11.319 7.785 2.898 11.355 7.761 2.942 stddev 0.033 0.019 0.040 0.057 0.033 0.063