[Issue 11783] Make std.datetime unittesting faster

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Dec 22 02:22:20 PST 2013


https://d.puremagic.com/issues/show_bug.cgi?id=11783



--- Comment #6 from Andrei Alexandrescu <andrei at erdani.com> 2013-12-22 02:21:52 PST ---
(In reply to comment #5)
> It wouldn't surprise me if _assertPred adds quite a bit to it, because of all
> of the template instantiations that get generated for it. That might be part of
> why the tests take so long. Some of the tests were refactored to use plain
> assertions after assertPred failed to get through the review process, but a
> good chunk of them still use _assertPred, so if those template instantions
> incur enough of a performance hit, then removing those may help cut down on the
> compilation time for the tests (AFAIK, the time for the tests includes both the
> compilation time and the running time, but I don't know - if it's just the
> running time, then this probably isn't a factor).
> 
> I do know for a fact though that the assertThrown tests are very expensive and
> cut down on them at one point because of the ridiculously low performance of D
> exceptions. I really don't like cutting out too many of them, as I think that
> the failure cases should be well tested as well, but it's possible that those
> tests alone are a large portion of the running time. That's why I really wish
> that issue# 9584 would get some attention. Exception performance is one place
> where Java completely blows us out of the water, and while it might not matter
> a lot for production code (as exceptions should be relatively rare there), it's
> very detrimental to unit tests which test failure cases.

I understand you consider the speed of throwing exceptions an important factor
here. I'm sorry I haven't been equally clear about expressing my point. It is
my opinion that the test taking long is a systemic problem with the unittests
in std.datetime, not with the speed of D exceptions. Improving the latter is of
course desirable but that is largely independent of the issue at hand.

Thirty-eight seconds is an eternity in CPU time. One would need to exercise a
large amount of abuse on the CPU to even get in that vicinity - especially if
files and networks are not being used. Conversely, it should be fairly easy to
eliminate that abuse. A quick browse shows things like

        foreach(year; chain(testYearsBC, testYearsAD))
        {
            foreach(md; testMonthDays)
            {
                foreach(tod; testTODs)
                {
                    auto dt = DateTime(Date(year, md.month, md.day), tod);

                    foreach(tz; testTZs)
                    {
                        foreach(fs; testFracSecs)
                            test(SysTime(dt, fs, tz), year);
                    }
                }
            }
        }

I have no idea whether that's a major contributor to the total runtime, but on
the face of it five nested loops are what they are and most likely are testing
redundantly an awfully small area of code.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list