http://d.puremagic.com/issues/show_bug.cgi?id=3463
--- Comment #48 from Leandro Lucarella <llu...@gmail.com> 2010-07-25 17:04:56 PDT --- Well timings for dil are much worse :( This is dil generating the Tango docs, without precise scanning (dmd with the last patch, Tango unpatched): 52.01 53.73 52.21 51.79 50.58 52.62 53.01 48.49 51.51 49.68 min = 48.49 mean = 51.563, std = 1.58236847795 max = 53.73 And this is with precise scanning: 79.47 69.81 72.27 67.12 68.34 83.85 65.28 75.17 77.76 74.73 min = 65.28 mean = 73.38, std = 5.91698309013 max = 83.85 I can't explain why is even less stable with precise scanning, maybe is something to do with it being less cache-friendly. I don't know either why is so stable without precise scanning, when in other tests I've done it wasn't like that. Maybe the majority of false positives are from the static memory and the binary was placed in an address that make them less probable (the binary address doesn't change between runs). It would be nice if other people give this patches a try, specially with programs that have problems with false positives... Here are the profiling results (using perf[1]): Non-precise scanning: http://pastebin.com/zRKyc9mW Precise scanning: http://pastebin.com/jPJZLL8p It looks like findPool() might be used much more often than before? For example, I noticed the mixin code calls findPool() very early, so maybe it's being called in some situations where it's not necessary. Also, with the patch sizeOf() needs to call findPool(), but I don't think that should make a lot of difference (unless is used by the runtime very often for array manipulation). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
