On 6/25/2013 2:27 AM, Kiith-Sa wrote:
> TLDR: gprof is horrible. Never use it for profiling. There are approximaly 5
> billion better tools that give more detailed results _and_ are easier to use.

One thing gprof does give is accurate counts, and accurate fan in / fan out data. The fan data is very useful in finding out who is calling who and how many times.

> I seriously need to write a blog post/article about this.

Please do so!

On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote:

> so it could be std library implementation related - can DMC use the msvc libs? (just for the compare)
>
> and you should also try 2010 - or better 2012 msvc (it still gets speedier code out)

Is there still a free version of the VS compiler ?

On Wednesday, 26 June 2013 at 05:39:00 UTC, SomeDude wrote:
> On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote:
>
>> so it could be std library implementation related - can DMC use the msvc libs? (just for the compare)
>>
>> and you should also try 2010 - or better 2012 msvc (it still gets speedier code out)
>
> Is there still a free version of the VS compiler ?

Ah yes, Visual Studio Express 2012 is free.

On Wednesday, June 26, 2013 07:38:51 SomeDude wrote:
> On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote:
> > so it could be std library implementation related - can DMC use
> > the msvc libs? (just for the compare)
> > 
> > and you should also try 2010 - or better 2012 msvc (it still
> > gets speedier code out)
> 
> Is there still a free version of the VS compiler ?

Yes.

http://www.microsoft.com/visualstudio/eng/downloads

Though it's obviously going to be a stripped down version.

- Jonathan M Davis

On Monday, 24 June 2013 at 18:01:11 UTC, Walter Bright wrote:
> On 6/24/2013 6:19 AM, dennis luehring wrote:
>> how does that look using msvc compiling the dmd compiler
>> as it turns out that msvc make dmd much faster
>
> The profile report was done by gcc/gprof.
>
> And besides, better compilers shouldn't change profile results.

I'm confused.... Different optimisers often produce radically different profile results. Or are am I misunderstanding you?

Am 26.06.2013 07:38, schrieb SomeDude:
> On Monday, 24 June 2013 at 16:46:51 UTC, dennis luehring wrote:
>
>> so it could be std library implementation related - can DMC use
>> the msvc libs? (just for the compare)
>>
>> and you should also try 2010 - or better 2012 msvc (it still
>> gets speedier code out)
>
> Is there still a free version of the VS compiler ?
>

always the latest (currently) vs2012 as express edition (only the MFC library is missing)

Am 26.06.2013 08:47, schrieb John Colvin:
> On Monday, 24 June 2013 at 18:01:11 UTC, Walter Bright wrote:
>> On 6/24/2013 6:19 AM, dennis luehring wrote:
>>> how does that look using msvc compiling the dmd compiler
>>> as it turns out that msvc make dmd much faster
>>
>> The profile report was done by gcc/gprof.
>>
>> And besides, better compilers shouldn't change profile results.
>
> I'm confused.... Different optimisers often produce radically
> different profile results. Or are am I misunderstanding you?
>

maybe he talk about the dmd -release parameter but even that should produce different results (or is the same code use the same amount?)

On Tuesday, 25 June 2013 at 16:56:55 UTC, Andrei Alexandrescu wrote:
> On 6/25/13 2:13 AM, Iain Buclaw wrote:
>> On 25 June 2013 07:46, Marco Leise<Marco.Leise@gmx.de>  wrote:
>>> Am Mon, 24 Jun 2013 21:01:36 +0200
>>> schrieb Martin Nowak<code@dawg.eu>:
>>>
>>>> On 06/24/2013 08:43 PM, Martin Nowak wrote:
>>>>>
>>>>> I can try to install kernel debuginfo that 12% might contain some useful
>>>>> information.
>>>>
>>>> http://codepad.org/gWrGvm40
>>>
>>> Interesting. So to troll a bit, do I see it right, that dmd is
>>> mostly a Unicode conversion and memory allocation tool ?
>>>
>>
>> The D front end does nothing *but* allocate memory... and sometimes
>> from all this allocation (if your computer doesn't die) a compiled
>> program is produced.
>
> Then maybe it should use its own malloc that uses the bump-the-pointer approach from large chunks allocated with malloc.

The problem is not that malloc is slow, but malloc is being called too much.

A hierarchical profile would be more useful here, to see exactly what's allocating all that memory. I'm also intrigued as to why so much string activity is happening (vfprintf!? num_to_str!?)