Hello,


There have been some changes in the way phobos unittests are run, which I must have missed. For the most part I'm noticing a significant slowdown, and -j does not help as much as it used to.

Is there a summary for these changes so I don't need to rummage through the code?


Thanks,

Andrei
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

This seems to be http://goo.gl/NnX2Mq. It's quite a bummer because I have plenty of memory on my laptop and used this kind of command frequently:

make generated/osx/debug/64/unittest/std/algorithm BUILD=debug MODEL=64

In the old version that would build phobos in one invocation of dmd, and then only the unittest for algorithm. That all was a few seconds. Now the command (after only touching std/algorithm.d) takes 55 seconds, and trying different -jN options don't help much beyond freezing my machine for a few seconds.

That's a huge pessimization, the kind that impacts working on Phobos significantly. Can we have some of both worlds, i.e. an option to enable compile-at-once vs. compile separately?


Thanks,

Andrei

On 10/26/13 9:26 PM, Andrei Alexandrescu wrote:
> Hello,
>
>
> There have been some changes in the way phobos unittests are run, which
> I must have missed. For the most part I'm noticing a significant
> slowdown, and -j does not help as much as it used to.
>
> Is there a summary for these changes so I don't need to rummage through
> the code?
>
>
> Thanks,
>
> Andrei
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

The thundering silence in response to my concern below is that apparently one order of magnitude slowdown in unittesting speed is not important :o).

Anyhow, I posted https://github.com/D-Programming-Language/phobos/pull/1768 that attempts to make that better.

However, I have to question the rationale of the entire change. I think the right way to unittest is build ONE phobos module with -unittest, link it against libphobos, and run unittest. The symbols defined in that module will override the symbols defined by that same module inside the library, and the rest of the library will be pulled in appropriately.

This is exactly as unittests should be run - unittest one "unit" at a time.

Why have things been changed to painstakingly build one executable containing all modules built with -unittest?

If no good reason comes forward, I propose we change things.


Andrei


On 10/26/13 10:00 PM, Andrei Alexandrescu wrote:
> This seems to be http://goo.gl/NnX2Mq. It's quite a bummer because I
> have plenty of memory on my laptop and used this kind of command
> frequently:
>
> make generated/osx/debug/64/unittest/std/algorithm BUILD=debug MODEL=64
>
> In the old version that would build phobos in one invocation of dmd, and
> then only the unittest for algorithm. That all was a few seconds. Now
> the command (after only touching std/algorithm.d) takes 55 seconds, and
> trying different -jN options don't help much beyond freezing my machine
> for a few seconds.
>
> That's a huge pessimization, the kind that impacts working on Phobos
> significantly. Can we have some of both worlds, i.e. an option to enable
> compile-at-once vs. compile separately?
>
>
> Thanks,
>
> Andrei
>
> On 10/26/13 9:26 PM, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> There have been some changes in the way phobos unittests are run, which
>> I must have missed. For the most part I'm noticing a significant
>> slowdown, and -j does not help as much as it used to.
>>
>> Is there a summary for these changes so I don't need to rummage through
>> the code?
>>
>>
>> Thanks,
>>
>> Andrei
_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos

On 12 dec 2013, at 20:54, Andrei Alexandrescu <andrei@erdani.com> wrote:

> The thundering silence in response to my concern below is that apparently one order of magnitude slowdown in unittesting speed is not important :o).

I think it's very important that tests run as fast as possible.

> Anyhow, I posted https://github.com/D-Programming-Language/phobos/pull/1768 that attempts to make that better.
> 
> However, I have to question the rationale of the entire change. I think the right way to unittest is build ONE phobos module with -unittest, link it against libphobos, and run unittest. The symbols defined in that module will override the symbols defined by that same module inside the library, and the rest of the library will be pulled in appropriately.
> 
> This is exactly as unittests should be run - unittest one "unit" at a time.

With the Ruby on Rails testing framework I use at work it's possible to run all the tests, all the tests of a single file or only a single test in a file. I think all these cases are useful.

I would guess many would just invoke dmd to run the unit tests of a single file:

$ make ...
$ dmd -main -unittest -run std/algorithm.std

-- 
/Jacob Carlborg


_______________________________________________
phobos mailing list
phobos@puremagic.com
http://lists.puremagic.com/mailman/listinfo/phobos