Integrated code formatter

[H. S. Teoh]

On Tue, Jan 18, 2022 at 01:30:56AM +0000, max haughton via Digitalmars-d wrote:
[...]
> 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.

Given the frequency of std.array.array in range-based D code, which
currently is completely not tracked by -profile=gc, I honestly doubt how
useful this is. Basically you'd only be detecting array literals, AA
literals, and the odd array length changes. Anything constructed from
ranges would be missed.  At least for the kind of code I write, that's
like >80% of GC allocations, making this "feature" next to useless to
me.

At the very least, the documentation should clearly state what is/isn't
traced by -profile=gc.  The current misleading state of things is a big
turn-off for newcomers.


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

I concur.  Last time I checked (this was a few years ago), it uses
16-bit counters internally to track function call counts. **16-bit**
counters!!!  Makes it completely worthless for profiling anything that
runs for non-trivial amounts of time.  The counters overflow in the
steady state and produce useless garbled output.  It's a total sham.
Kill it with fire, I say.


T

-- 
If you're not part of the solution, you're part of the precipitate.