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.