Consider adding link-time optimisation (-lto) build option

[woollybah]

Link-time optimisation (some info here and here ) can potentially create smaller, faster binaries.

The main caveat is longer build times - because the compiler makes more than 1 pass over the code, performing more analysis.

So this would be an option you'd enable later in your process, rather than during heavy development.

We may need some non-scientific benchmarks to see if this makes much of a different to BlitzMax apps.

[woollybah]

As a random example of lto to create smaller files, I did a test on tarraylist_sort.bmx from the brl.collections doc folder.
The standard release build created a file of 463133 bytes.
With an lto release build, it created a file of 377962 bytes.

I would guess the % savings are likely to decrease as the binary gets larger.

[Kerntrick]

20% is not bad. It could be good as an option for making public release builds. For me, compile time trumps runtime most of the time.
On the subject of optimization, NG could really use a profiler.
Is there a way sample the state of 'OnDebugEnterStm' with another thread at runtime to do some basic profiling? It's a terrible idea, but desperate times.....

[braxtonrivers]

I know that I am late to this, lto is a great idea, I have been testing this with /Os and am happy with the results.