Optimization fun

[Sean Kelly via Digitalmars-d]

On Thursday, 6 November 2014 at 23:00:19 UTC, H. S. Teoh via
Digitalmars-d wrote:
> So today, I was playing around with profiling and optimizing my 
> sliding
> block puzzle solver, and found some interesting things:
>
> 1) The GC could use some serious improvement: it just so 
> happens that
> the solver's algorithm only ever needs to allocate memory, 
> never release
> it (it keeps a hash of visited states that only grows, never 
> shrinks).
> The profiler indicated that one of the hotspots is the GC. So I 
> added an
> option to the program to call GC.disable() if a command line  
> option is
> given. The result is a 40%-50% reduction in running time.

We've talked before about keeping statistics of how much memory
has been reclaimed by collections, and use that to influence
whether a collection should be run before going to the OS for
more.  Something like this should definitely get a bugzilla
ticket.

For now, you might want to consider guessing at how much memory
you'll need and calling GC.reserve() as well.  This should
improve the performance of your app even further.


> 2) Auto-decoding is evil

Yep, it's the worst.  Most string operations don't even need
auto-decoding to work properly.  I honestly have no idea why we
have this feature.