On 31 October 2013 01:01, Mike Stump <mikest...@comcast.net> wrote:
> On Oct 30, 2013, at 2:41 AM, Bernhard Reutner-Fischer <rep.dot....@gmail.com>
> wrote:
>>> I've noticed that this testcase doesn't clean up after itself.
>
>> This was nagging me last weekend.. ;)
>> What about automating this?
>
> So, the idea sounds very nice.
>
> One thing that I worry about is the testing speed hit for people (test cases)
> that don't need cleanups. I don't know the speed hit of the code, so, don't
> know how necessary it is to try and go faster.
>
> I was thinking the presence of a scan-tree-dump, would set a bit that said,
> do a scan-tree-dump style cleanup.
Well, since the -fdump-* are the one to produce the dumps, i keyed the
cleanup off that.
Initially i had the idea to use an exact per-pass wiper but that
turned out to be too complicated for no real benefit.
>
> The common code then does, if cleanups needed, do cleanups
>
> The idea, most test cases don't do this, and don't need the big cleanup
> routine to fire. A scan-tree-dump would setup a cleanup tree dumps flags,
> and then in the big cleanup routine, you have:
The cleanup routine would currently run 7 regexes on the incoming
compiler-flags which is supposedly pretty fast.
But yes, we could as well key off scan-dump. If we do that, i'd
suggest to simply wipe all potential dumps, regardless of the "family"
etc, like:
"$ltrans\[0-9\]\[0-9\]\[0-9\][itr].*"
What do you think?
>
> do cleanups()
> {
> if (need tree cleanups) do tree cleanups();
> if (need rtl cleanups) do rtl cleanups();
> }
>
> this way, we avoid randomly doing cleanups for things we don't need them for,
> and avoid even asking if we need any cleanups, as we can have a global flag
> that says if we need any extra, special cleanups.
>
> So, all that would be bad to do, if the speed hit is small… Can you collect
> with/without numbers and post them? If you can, include user, sys and
> elapsed. You can run a subset of one testsuite, say, dg.exp, as
> representative.
The pristine trunk, i.e. with manual cleanup was a couple of seconds
slower than with the patch (10s or 20s IIRC, let me measure this on an
idle box again now).
As you can see, the number of globs before and after the patch
decreases quite a lot, i guess the fact that we glob less is
responsible for the improved runtime. Let me double-check that,
though.
thanks,
