On 9/8/2016 4:26 AM, Ethan Watson wrote:
On Thursday, 8 September 2016 at 11:18:12 UTC, Walter Bright wrote:
The thing is, the 'destroy()' function is going to swamp any extra clock
cycle, as will a virtual lookup and dereference.
Assume destroy() is a more trivial function then. The point is that if you put
more than two branches in a 64-byte cacheline on that processor, things get
significantly slower and the loop iteration itself becomes a hotspot.
Putting a destructor call in a tight loop is probably not a good pattern. Hoist
it out of the loop.
Being D though. Destructors can be contracted, yeah? Because the way we operate
is that we compile out all those validation checks for a retail release and
assume everything works. Checking for the validity of the pointer in an in block
would be perfect for that.
Sounds good!
