General performance tip about possibly using the GC or not

[Jon Degenhardt via Digitalmars-d-learn]

On Tuesday, 29 August 2017 at 00:52:11 UTC, Cecil Ward wrote:
> I am vacillating - considering breaking a lifetime's C habits 
> and letting the D garbage collector make life wonderful by just 
> cleaning up after me and ruining my future C disciple by not 
> deleting stuff myself.
>
The tsv command line tools I open-sourced haven't any problems 
with GC. They are only one type of app, perhaps better suited to 
GC than other apps, but still, it is a reasonable data point. 
I've done rather extensive benchmarking against similar tools 
written in native languages, mostly C. The D tools were faster, 
often by significant margins. The important part is not that they 
were faster on any particular benchmark, but that they did well 
against a fair variety of tools written by a fair number of 
different programmers, including several standard unix tools. The 
tools were programmed using the standard library where possible, 
without resorting to low-level optimizations.

I don't know if the exercise says anything about GC vs manual 
memory management from the perspective of maximum possible code 
optimization. But, I do think it is suggestive of benefits that 
may occur in more regular programming, in that GC allows you to 
spend more time on other aspects of your program, and less time 
on memory management details.

That said, all the caveats, suggestions, etc. given by others in 
this thread apply to my programs to. GC is hardly a free lunch.

Benchmarks on the tsv utilities: 
https://github.com/eBay/tsv-utils-dlang/blob/master/docs/Performance.md

Blog post describing some of the techniques used: 
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

--Jon