On Tuesday, 31 December 2013 at 06:28:40 UTC, Ola Fosheim Grøstad
wrote:
A flexible new and good compiler level memory management
support that cannot be overridden gives the compiler some
optimization opportunities. E.g. putting objects on the stack,
allocating a single chunk for multiple objects, delaying init
and perhaps avoiding allocation.
So I am personally sceptical of pushing libraries over advanced
compiler support. Leaving more room for analysis is usually a
good thing.
Well, that's certainly a good point. There's _probably_ some
extra optimizations that could be done with a compiler supported
new. Maybe it could make some significantly faster code, but this
assumes many things:
1. The compiler writer will actually do this analysis and write
the optimization (my bets are that DMD will likely not do many of
the things you suggest).
2. The person writing the code is writing code that is allocating
several times in a deeply nested loop.
3. Despite the person making the obvious critical error of
allocating several times in a deeply nested loop, he must not
have made any other significant errors or those other errors must
also be covered by optimizations.
4. The allocation isn't passed around too much to avoid the
analysis or isn't actually kept around sometimes for some reason
This makes the proposed optimization _very_ situational. If the
situation does occur, it's possible that the user can use
something like "std.allocator.StackAllocator" to do what he
needs. Manual optimization in this case isn't too unreasonable.
Considering the drawbacks of new and the advantages of a library
allocation, this additional _potential_ advantage of new isn't
enough to suggest its usage over a library solution here. Again,
it's not a bad point, but it's just not compelling enough.
That all said,
The issue I have with library level allocation is that the
compiler does not know that the code is doing allocation?
_Technically_ the compiler could also do some analysis in
functions and figure out that it will be allocating in there
somewhere and using that allocation later on. Think of replacing
library calls when it's noticed that it's an allocate function.
It's pretty dirty and won't actually happen nor do I suggest it
should happen, but it's actually still also _possible_.
