D perfomance

[Joseph Rushton Wakeling]

On Saturday, 25 April 2020 at 22:15:44 UTC, Walter Bright wrote:
> My experience is if the code has never been profiled, there's 
> one obscure function unexpectedly consuming the bulk of the run 
> time, which is easily recoded. A programs that have been 
> runtime profiled tend to have a pretty flat graph of which 
> functions eat the time.

Yes! :-)  And in particular, that computational complexity in the 
real world is very different from theoretical arguments about 
O(...).  One can gain a lot by being clear headed about what the 
actual problem is and what is optimal for that particular problem 
with that particular data.

> This is why I use OutBuffer for such activities.

Yes, I have some memory of talking with Dicebot about whether 
this would be an appropriate tool for the other side of the D2 
conversion.  I don't remember if any firm conclusions were drawn, 
though.

> Sounds like an idea worth exploring. How about taking point on 
> that? But I would be concerned about tagging such arrays, and 
> then stomping them unintentionally, leading to memory 
> corruption bugs. OutBuffer is memory safe.

Yes, it's clear (as Jonathan noted) that an always-stompable 
array could probably not be @safe.  That said, what does 
OutBuffer do that means that it _is_ safe in this context?

Of course, Sociomantic never had @safe to play with.  In practice 
I don't recall there ever being an issue with unintentional 
stomping (I'm not saying it never happened, but I have no 
recollection of it being a common issue).  That did however rest 
on a program structure that made it less likely anyone would make 
such a mistake.

About stepping up with a feature contribution: the idea is lovely 
but I'm very aware of how limited my time is right now, so I 
don't want to make offers I can't guarantee to follow up on.  
There's a reason I post so rarely in the forums these days!  But 
I will ping Mathias L. to let him know, as the idea was his to 
start with.