Integrated code formatter

max haughton maxhaton at gmail.com
Tue Jan 18 01:30:56 UTC 2022


On Tuesday, 18 January 2022 at 01:23:26 UTC, H. S. Teoh wrote:
> On Mon, Jan 17, 2022 at 05:01:53PM -0800, H. S. Teoh via 
> Digitalmars-d wrote:
>> On Tue, Jan 18, 2022 at 12:40:17AM +0000, forkit via 
>> Digitalmars-d wrote: [...]
>> > https://issues.dlang.org/show_bug.cgi?id=14892
>> 
>> Alright.  Since you brought it up, I'm gonna try to take a 
>> look sometime and see if it's simple enough for me to fix.  
>> I'm not very familiar with dmd's code, but I *have* fixed a 
>> bug or two before so I'm gonna take a shot at it.  No 
>> guarantees, though! ;-)
> [...]
>
> OK, first impressions: -profile=gc is a crock.  Not only it 
> fails to detect GC allocations outside of built-in language 
> constructs, it fails to create the profilegc.txt output file at 
> all when it detects no allocations.  I wrote a test program 
> that allocates an array with a literal, then commented it out 
> to an empty main(), profilegc.txt was NOT updated. :-/
>
> Honestly, at this point I'd recommend just doing this instead 
> of using -profile=gc at all:
>
> 	import core.memory : GC;
> 	writeln(GC.stats);
>
> That will tell you the real honest truth of what has actually 
> been allocated on the GC, straight from the GC horse's mouth. 
> No compiler lies.
>
> I'll take a look at the code now to see if there's anything 
> easily salvageable...  but at this point I'm ready to propose 
> pulling the trigger on -profile=gc completely.  (Based on how I 
> suspect it works, I'm expecting that it would not be easy to 
> implement any useful output for allocations via druntime 
> functions -- at best you'd just get some obscure file/line 
> number inside druntime code which would be of no help locating 
> where in *your* code the allocation happened.)
>
>
> T

On Linux and anything with DTrace at least it might be possible 
to replace it with a some eBPF (or DTrace) code.

Profile=GC is still useful however. Catching *all* allocations 
isn't actually particularly important in steady state. The 
allocations that matter are nearly always extremely obvious. 
Profile=GC can do a better job than a normal heap profiler 
because it has access to the typeinfo.

-profile is total rubbish that should be gotten rid of entirely. 
No prisoners, no prisoners.



More information about the Digitalmars-d mailing list