I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd 2.063.2 generates in debug mode is significantly slower then the code generated by dmd 2.062. Have there been changes to the debug mode that affect execution speed? Like additional debug checks?

Kind Regards
Benjamin Thaut

On 10/13/2013 11:29 PM, Benjamin Thaut wrote:
> I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd
> 2.063.2 generates in debug mode is significantly slower then the code generated
> by dmd 2.062. Have there been changes to the debug mode that affect execution
> speed? Like additional debug checks?

Not aware of any such changes.

Am 14.10.2013 09:09, schrieb Walter Bright:
> On 10/13/2013 11:29 PM, Benjamin Thaut wrote:
>> I just upgraded from dmd 2.062 to dmd 2.063.2 and I see that the code dmd
>> 2.063.2 generates in debug mode is significantly slower then the code
>> generated
>> by dmd 2.062. Have there been changes to the debug mode that affect
>> execution
>> speed? Like additional debug checks?
>
> Not aware of any such changes.
>

I actually found it. I havily use core.sys.windows.stacktrace in my code and I did make some modifications on my druntime branch which I accidentially reverted when merging in druntime 2.063.2
These changes make stacktracing on windows faster by a factor of 10. Thats why I see such a performance impact with dmd 2.063

I'm currently preparing a pull request for this but I ran into an issue. When compiling the latest druntime with the latest dmd for windows 32-bit I get the following error message:

lib\druntime.lib: Error: corrupt object module

On windows 64-bit everything works fine. Any ideas why this happens?

Kind Regards
Benjamin Thaut

On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
> When
> compiling the latest druntime with the latest dmd for windows 32-bit I get the
> following error message:
>
> lib\druntime.lib: Error: corrupt object module
>
> On windows 64-bit everything works fine. Any ideas why this happens?

It means it isn't a correct 32 bit object file.

Am 14.10.2013 10:56, schrieb Walter Bright:
> On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
>> When
>> compiling the latest druntime with the latest dmd for windows 32-bit I
>> get the
>> following error message:
>>
>> lib\druntime.lib: Error: corrupt object module
>>
>> On windows 64-bit everything works fine. Any ideas why this happens?
>
> It means it isn't a correct 32 bit object file.
>

And what could cause this? I already tried manually deleting everything thats not checked into git. "make -f win32.mak clean" doesn't help either.

On 10/14/2013 1:57 AM, Benjamin Thaut wrote:
> Am 14.10.2013 10:56, schrieb Walter Bright:
>> On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
>>> When
>>> compiling the latest druntime with the latest dmd for windows 32-bit I
>>> get the
>>> following error message:
>>>
>>> lib\druntime.lib: Error: corrupt object module
>>>
>>> On windows 64-bit everything works fine. Any ideas why this happens?
>>
>> It means it isn't a correct 32 bit object file.
>>
>
> And what could cause this? I already tried manually deleting everything thats
> not checked into git. "make -f win32.mak clean" doesn't help either.

I can't reproduce that error, and neither can the autotester.

Am 14.10.2013 11:01, schrieb Walter Bright:
> On 10/14/2013 1:57 AM, Benjamin Thaut wrote:
>> Am 14.10.2013 10:56, schrieb Walter Bright:
>>> On 10/14/2013 12:24 AM, Benjamin Thaut wrote:
>>>> When
>>>> compiling the latest druntime with the latest dmd for windows 32-bit I
>>>> get the
>>>> following error message:
>>>>
>>>> lib\druntime.lib: Error: corrupt object module
>>>>
>>>> On windows 64-bit everything works fine. Any ideas why this happens?
>>>
>>> It means it isn't a correct 32 bit object file.
>>>
>>
>> And what could cause this? I already tried manually deleting
>> everything thats
>> not checked into git. "make -f win32.mak clean" doesn't help either.
>
> I can't reproduce that error, and neither can the autotester.

I found it: src\rt\minit.obj is corrupt. When I copy the file from the 2.064 beta package it builds sucessfully. Might have to do something with the line ending settings in git.

Maybe a .gitattributes file setting *.obj to binary should be added to the druntime repository to prevent issues like this.

Kind Regards
Benjamin Thaut

Am 14.10.2013 09:24, schrieb Benjamin Thaut:
>
> I actually found it. I havily use core.sys.windows.stacktrace in my code
> and I did make some modifications on my druntime branch which I
> accidentially reverted when merging in druntime 2.063.2
> These changes make stacktracing on windows faster by a factor of 10.
> Thats why I see such a performance impact with dmd 2.063
>

https://github.com/D-Programming-Language/druntime/pull/638

On Mon, 14 Oct 2013 11:09:54 +0200
Benjamin Thaut <code@benjamin-thaut.de> wrote:
> 
> I found it: src\rt\minit.obj is corrupt. When I copy the file from the 2.064 beta package it builds sucessfully. Might have to do something with the line ending settings in git.
> 
> Maybe a .gitattributes file setting *.obj to binary should be added to the druntime repository to prevent issues like this.
> 

Automatic line ending conversions need to be nuked from existence. Git's EOL-conversion "feature" should never have existed in the first place. I can only imagine it happened because some early Git developer must have thought Windows was still stuck in 1991. Or maybe they thought Windows developers write code in notepad.

*Any* Git installation that has any form of EOL-conversions enabled is absolutely in error and will eventually just breed problems. And any sane editor will respect the line endings of any file it opens, if it doesn't it's a POS and needs to be fixed/replaced. So there should never be any problem, and never be any need for any of Git's "helpful" automatic data butchering.

(Same goes for FTP, but at least FTP has an excuse: It existed back when there *was* such as thing as "Unix line endings" and "Windows line endings".)

Am 14.10.2013 13:30, schrieb Nick Sabalausky:
> On Mon, 14 Oct 2013 11:09:54 +0200
> Benjamin Thaut <code@benjamin-thaut.de> wrote:
>>
>> I found it: src\rt\minit.obj is corrupt. When I copy the file from
>> the 2.064 beta package it builds sucessfully. Might have to do
>> something with the line ending settings in git.
>>
>> Maybe a .gitattributes file setting *.obj to binary should be added
>> to the druntime repository to prevent issues like this.
>>
>
> Automatic line ending conversions need to be nuked from existence.
> Git's EOL-conversion "feature" should never have existed in the first
> place. I can only imagine it happened because some early Git developer
> must have thought Windows was still stuck in 1991. Or maybe they
> thought Windows developers write code in notepad.
>
> *Any* Git installation that has any form of EOL-conversions enabled is
> absolutely in error and will eventually just breed problems. And any
> sane editor will respect the line endings of any file it opens, if it
> doesn't it's a POS and needs to be fixed/replaced. So there should never
> be any problem, and never be any need for any of Git's "helpful"
> automatic data butchering.
>
> (Same goes for FTP, but at least FTP has an excuse: It existed back
> when there *was* such as thing as "Unix line endings" and "Windows line
> endings".)
>

Visual Studio requests CRLF file endings...

But I fully agree CRLF should die.

Kind Regards
Benjamin Thaut