Walter Bright Wrote:

> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.036.zip
> 

Great!

I failed to compile Tango svn trunk with 1.036, but Tango 0.99.7, compiled with 1.035, works fine.

I got a small fps boost when compiled my graphics engine with new dmd - maybe some improvements in associative arrays operations?.. Fps stability also improved.

When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With 1.036 it took 16.74 seconds and lib size became 8.1. I get same results with "-lib" while compiling derelict opengl and glu - it now takes a bit longer and produces bigger libs. Have you changed something?

On Fri, Oct 24, 2008 at 1:59 AM, digited <digited@yandex.ru> wrote:
> Walter Bright Wrote:
>
>>
>> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.036.zip
>>
>
> Great!
>
> I failed to compile Tango svn trunk with 1.036, but Tango 0.99.7, compiled with 1.035, works fine.
>
> I got a small fps boost when compiled my graphics engine with new dmd - maybe some improvements in associative arrays operations?.. Fps stability also improved.
>
> When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With 1.036 it took 16.74 seconds and lib size became 8.1. I get same results with "-lib" while compiling derelict opengl and glu - it now takes a bit longer and produces bigger libs. Have you changed something?

I have no idea why the generated code got bigger again, but it's far
from being the first time.
Check the graph here:
http://www.billbaxter.com/techblog/?p=9


--bb

digited wrote:
...
> When I was compiling DWT with 1.035 in a single command to dmd (dmd -lib modules), it took 11.66 seconds on 2GHz processor, size of lib was 7.6MB. With 1.036 it took 16.74 seconds and lib size became 8.1. I get same results with "-lib" while compiling derelict opengl and glu - it now takes a bit longer and produces bigger libs. Have you changed something?
> 
> 

I tried building DWT with -lib when that feature was first added.  -lib seems to be broken somehow, because just compiling one file at a time results in a much smaller .lib file.

Bill Baxter Wrote:

> I have no idea why the generated code got bigger again, but it's far
> from being the first time.
> Check the graph here:
> http://www.billbaxter.com/techblog/?p=9
> 
> 
> --bb

I thought this bug was a feature... Back to 1.035 then.

torhu Wrote:

> 
> I tried building DWT with -lib when that feature was first added.  -lib seems to be broken somehow, because just compiling one file at a time results in a much smaller .lib file.

That's normal (really a feature, not a bug) - "-lib" creates more than one object file from a module to make executables smaller (by linking not the full module object file, but it's piece that the executable really needs), it also does not any IO with hdd, all compiling and linking in RAM, so creating static libs is extremely fast and doesn't produce object files as output.

I've just compared "-lib" results from 1.035 and 1.036, it now works differently.

digited wrote:
> torhu Wrote:
> 
>> 
>> I tried building DWT with -lib when that feature was first added.  -lib seems to be broken somehow, because just compiling one file at a time results in a much smaller .lib file.
> 
> That's normal (really a feature, not a bug) - "-lib" creates more than one object file from a module to make executables smaller (by linking not the full module object file, but it's piece that the executable really needs), it also does not any IO with hdd, all compiling and linking in RAM, so creating static libs is extremely fast and doesn't produce object files as output.
> 
> I've just compared "-lib" results from 1.035 and 1.036, it now works differently.

Sorry, what I meant to say was that the executable ends up bigger when using libs created with -lib.