in the last days I was busy gathering performance data
about the "class Use"-related changes.
I have nice measurements on a 8Gig MacPro with kimwitu++.
This is important to say, because this machine is
in plenty of memory, so swapping is not likely, which
means that in more constrained setups (when swapping
occurs) the use-diet approach is probably producing
even better results.
So here are my values when doing a
time make --always
in the regular trunk and with my changes merged in:
grep "^real" < kimwituRegular.scatter.backup2 | sort
grep "^real" < kimwituDiet.scatter.backup2 | sort
As you can see, the use-diet changes actually lower the build time
of kimwitu++! (this is as of yesterday's r50182).
Parity is not only reached, but surpassed. I am pretty happy
The second thing I wanted to report, that contrary to my previous
announcement there will be *no* API change needed, so there is no
need for conversions in other projects any more.
(The confusion came from my erroneous understanding, at some point,
that the defining value for a GlobalVariable cannot be changed and
must be present on construction.)
Bill asked for memory statistics, I shall get some as I get Shark
If I find the time I can even make some pretty graphs.
All in all, I am on track with merging the branch on trunk
by the end of this week.