Jump to page: 1 2
Thread overview
Tracing allocations with "new" in dmd
Jun 19, 2020
Guillaume Piolat
Jun 19, 2020
Stefan Koch
Jun 19, 2020
Guillaume Piolat
Jun 19, 2020
Walter Bright
Jun 19, 2020
Stefan Koch
Jun 19, 2020
Stefan Koch
Jun 19, 2020
Stefan Koch
Jun 19, 2020
Tim
Jun 19, 2020
Tim
Jun 19, 2020
kinke
Jun 20, 2020
kinke
Nov 11, 2022
FeepingCreature
Nov 11, 2022
Tejas
June 19, 2020
dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.

There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).

Would be in your debt for any ideas. Thanks!
June 19, 2020
On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>
> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>
> Would be in your debt for any ideas. Thanks!

-profile=gc ?
June 19, 2020
On 6/19/20 9:48 AM, Guillaume Piolat wrote:
> On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
>> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>>
>> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>>
>> Would be in your debt for any ideas. Thanks!
> 
> -profile=gc ?

Thanks, I'll look into it. Does it provide type information or only low-level allocated size information?
June 19, 2020
On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>
> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>
> Would be in your debt for any ideas. Thanks!

I have a tracing tool.
USE IT.
June 19, 2020
On Friday, 19 June 2020 at 14:19:36 UTC, Andrei Alexandrescu wrote:
> On 6/19/20 9:48 AM, Guillaume Piolat wrote:
>> On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
>>> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>>>
>>> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>>>
>>> Would be in your debt for any ideas. Thanks!
>> 
>> -profile=gc ?
>
> Thanks, I'll look into it. Does it provide type information or only low-level allocated size information?

gc profiling will not work UNLESS you use the `-lowmem` switch.
June 19, 2020
On Friday, 19 June 2020 at 14:19:36 UTC, Andrei Alexandrescu wrote:
>> 
>> -profile=gc ?
>
> Thanks, I'll look into it. Does it provide type information or only low-level allocated size information?

Here is an example of a profilegc.log file:

--------------- profilegc.log -----------


bytes allocated, allocations, type, function, file:line
           4096	              1	char[] D main source\main.d:36
            240	             10	main.main.D D main source\main.d:44
             64	              1	int[] D main source\main.d:37
             56	              1	double[] D main source\main.d:55


-----------------------------------------

June 19, 2020
On Friday, 19 June 2020 at 14:23:10 UTC, Stefan Koch wrote:
> On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
>> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>>
>> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>>
>> Would be in your debt for any ideas. Thanks!
>
> I have a tracing tool.
> USE IT.

it's here:
https://github.com/UplinkCoder/dmd/tree/dmd_tracing_2092

Currently I am still hunting down a bug which seems to be caused,
By tracing a temporary allocated, expression which will then lead to a segfault while writing the trace.

But I would very much like for others to use it, it's designed to allow you to say which source_code takes the most time out of the front-end process and where.

You will have to modify the source code of dmd to investigate particular issues,
But it comes with a number of likely candidates pre-selected for tracing.

I am happy to work with someone on up-streaming this and making it better.
June 19, 2020
On 6/19/20 10:23 AM, Stefan Koch wrote:
> On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
>> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>>
>> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>>
>> Would be in your debt for any ideas. Thanks!
> 
> I have a tracing tool.
> USE IT.

Cool, some links to docs would be great!
June 19, 2020
On Friday, 19 June 2020 at 14:42:27 UTC, Andrei Alexandrescu wrote:
> On 6/19/20 10:23 AM, Stefan Koch wrote:
>> On Friday, 19 June 2020 at 13:45:23 UTC, Andrei Alexandrescu wrote:
>>> dmd does most of its allcoation with new. I wonder what would be the easiest way to track how many instances of each type are created.
>>>
>>> There are over 3000 call sites, so ideally the changes to the source would be entirely automatic (e.g. with sed).
>>>
>>> Would be in your debt for any ideas. Thanks!
>> 
>> I have a tracing tool.
>> USE IT.
>
> Cool, some links to docs would be great!

There are no docs unfortunately.

I am happy to provide assistance and in the process of exploration the docs will be created as well.


June 19, 2020
On 6/19/20 10:34 AM, Guillaume Piolat wrote:
> On Friday, 19 June 2020 at 14:19:36 UTC, Andrei Alexandrescu wrote:
>>>
>>> -profile=gc ?
>>
>> Thanks, I'll look into it. Does it provide type information or only low-level allocated size information?
> 
> Here is an example of a profilegc.log file:
> 
> --------------- profilegc.log -----------
> 
> 
> bytes allocated, allocations, type, function, file:line
>             4096                  1    char[] D main source\main.d:36
>              240                 10    main.main.D D main source\main.d:44
>               64                  1    int[] D main source\main.d:37
>               56                  1    double[] D main source\main.d:55
> 
> 
> -----------------------------------------

Thanks. A quick experiment (built dmd itself with -profile=gc, ran it on a few simple files) seems to show that only array allocations are traced, but not allocations of individual objects.
« First   ‹ Prev
1 2