Haven't noticed that before. Does anyone know offhand of the reason?

Andrei

On Saturday, September 24, 2011 15:32:31 Andrei Alexandrescu wrote:
> Haven't noticed that before. Does anyone know offhand of the reason?

I'm betting it's the compilation time. It looks like it takes about 20 seconds on my machine in 64-bit Linux for debug and about 40 for release (timing it in my head, so I could be off by several seconds), but it takes about 26 milliseconds to run the tests in debug, and about 21 in release. So, clearly the compilation time is the much greater of the two.

My guess would be that it has to do with the foreach loops over TypeTuples that std.string uses to generate a number of its tests, but I don't know.

- Jonathan M Davis

On 9/24/11 4:25 PM, Jonathan M Davis wrote:
> My guess would be that it has to do with the foreach loops over TypeTuples that std.string uses to generate a number of its tests, but I don't know.

The test of tr is the culprit (shown at the bottom of this). It does a triple nested loop over string types.

Jonathan, did you time using the latest compiler? Walter, did you enable the GC for OSX too?

Should we disable this test, reduce it, or have Walter look into improving the compiler?


Thanks,

Andrei

unittest
{
     debug(string) printf("std.string.tr.unittest\n");
     import std.algorithm;

     foreach(S; TypeTuple!(char[], const(char)[], immutable(char)[],
                           wchar[], const(wchar)[], immutable(wchar)[],
                           dchar[], const(dchar)[], immutable(dchar)[]))
     {
         foreach(T; TypeTuple!(char[], const(char)[], immutable(char)[],
                               wchar[], const(wchar)[], immutable(wchar)[],
                               dchar[], const(dchar)[], immutable(dchar)[]))
         {
             foreach(U; TypeTuple!(char[], const(char)[], immutable(char)[],
                                   wchar[], const(wchar)[],
immutable(wchar)[],
                                   dchar[], const(dchar)[],
immutable(dchar)[]))
             {
                 ....
             }
         }

         auto s = to!S("hello world");
         static assert(is(typeof(s) == typeof(tr(s, "he", "if"))));
     }
}

On Saturday, September 24, 2011 18:55:19 Andrei Alexandrescu wrote:
> On 9/24/11 4:25 PM, Jonathan M Davis wrote:
> > My guess would be that it has to do with the foreach loops over TypeTuples that std.string uses to generate a number of its tests, but I don't know.
> The test of tr is the culprit (shown at the bottom of this). It does a triple nested loop over string types.
> 
> Jonathan, did you time using the latest compiler? Walter, did you enable the GC for OSX too?

I was probably a few commits off of the latest, but I just updated and tried again, and the results are pretty much the same. From the dmd-internals discussion on the GC stuff though, I got the impression that they only enabled it on Windows. I don't know though.

> Should we disable this test, reduce it, or have Walter look into improving the compiler?

I am of the opinion that the test should work and compile reasonably quickly. I have found tests like this to be very useful in finding problems relating to template constraints, constness, and encodings - particularly when dealing with the various string and character types. Granted, three levels of nesting of static foreach loops is a bit much (I think that the most that I normally end up with is two), but in this case, it was necessary to cover all of the combinations of types.

Now, it may be that we're going to need to disable this test temporarily on some set of platforms in order to reduce the time it takes to run the tests, but I am definitely of the opinion that the compiler should be fixed rather than us writing the tests off as infeasible. We can also reduce the number of test cases, but then it becomes much easier for bugs to get through which only affect a particular combination of character types and don't get caught.

And if this problem is due to the enabling of the GC at compile time, then it seems to me that this is a good test case in that it's catching a problem with the GC that needs to be fixed.

- Jonathan M Davis