On Mon, Jun 20, 2016 at 06:52:35PM +0200, Bernd Schmidt wrote: > On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote: > > In theory I would expect if anything this helps performance since it isn't > > necessary to malloc every time a node is added, however the data is less > > clear. > > Well, we have alloc pools for these lists, so a malloc is not needed for > every node.
its true, and lists.c has its own special cache, but still it is more than storing a pointer and incrementing the length I expect. > > fold const O2 new > > real 0m5.034s > > user 0m3.408s > > sys 0m0.364s > > > > fold const O2 old > > real 0m4.012s > > user 0m3.420s > > sys 0m0.340s > > So that's a second more in real time - was the machine very busy at the time > you ran these tests so that these aren't meaningful, or is there a need to > investigate this? Well, it was on my laptop which was running a web browser and stuff. I wasn't aware of it being busy, but it also wasn't a extra stable machine. I also noticed a bit of variance within the same configuration so I'm not terribly concerned, but it is odd. > > So a couple got about .3s slower, and others got about .1 faster, I'm not > > really sure but inclined to say any change is too small to easily measure. > > > > bootstrapped + regtested patches individually on x86_64-linux-gnu, ok? > > Modulo the question about compile times I think patches 1-4 are ok, In 5 and > 6 I see explicit for loops instead of FOR_EACH macros; I'm curious as to the > reason. uh, I suck and wasn't careful enough checking I fixed everything and I guess it was easy to forget since I've been destracted by other stuff. Sorry about that. Trev > > Bernd >
