Need for speed

[H. S. Teoh]

On Thu, Apr 01, 2021 at 07:25:53PM +0000, matheus via Digitalmars-d-learn wrote:
[...]
> Since this is a "Learn" part of the Foruam, be careful with
> "-boundscheck=off".
> 
> I mean for this little snippet is OK, but for a other projects this my
> be wrong, and as it says here:
> https://dlang.org/dmd-windows.html#switch-boundscheck
> 
> "This option should be used with caution and as a last resort to
> improve performance. Confirm turning off @safe bounds checks is
> worthwhile by benchmarking."
[...]

It's interesting that whenever a question about D's performance pops up
in the forums, people tend to reach for optimization flags.  I wouldn't
say it doesn't help; but I've found that significant performance
improvements can usually be obtained by examining the code first, and
catching common newbie mistakes.  Those usually account for the majority
of the observed performance degradation.

Only after the code has been cleaned up and obvious mistakes fixed, is
it worth reaching for optimization flags, IMO.

Common mistakes I've noticed include:

- Constructing large arrays by appending 1 element at a time with `~`.
  Obviously, this requires many array reallocations and the associated
  copying; not to mention greatly-increased GC load that could have been
  easily avoided by preallocation or using std.array.appender.

- Failing to move repeated computations (esp. inefficient ones) outside
  the inner loop.  Sometimes a good optimizing compiler is able to hoist
  it out automatically, but not always.

- Constructing lots of temporaries in inner loops as heap-allocated
  classes instead of by-value structs: the former leads to heavy GC
  load, not to mention memory allocation is generally slow and should be
  avoided inside inner loops. Heap-allocated objects also require
  indirections, which slow things down even more. The latter can be
  passed around in registers: no GC pressure, no indirections; so can
  significantly improve performance.

- Using O(N^2) (or other super-linear) algorithms with large data sets
  where a more efficient algorithm is available. This one ought to speak
  for itself. :-D  Nevertheless it still crops up from time to time, so
  deserves to be mentioned again.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.