D perfomance

[Joseph Rushton Wakeling]

On Sunday, 26 April 2020 at 16:20:19 UTC, Steven Schveighoffer 
wrote:
> In terms of performance, depending on the task at hand, D1 code 
> is slower than D2 appending, by the fact that there's a 
> thread-local cache for appending for D2, and D1 only has a 
> global one-array cache for the same. However, I'm assuming that 
> since you were focused on D1, your usage naturally was written 
> to take advantage of what D1 has to offer.
>
> The assumeSafeAppend call also uses this cache, and so it 
> should be quite fast. But setting length to 0 is a ton faster, 
> because you aren't calling an opaque function.
>
> So depending on the usage pattern, D2 with assumeSafeAppend can 
> be faster, or it could be slower.

That makes sense.  I just know that Mathias L. seemed to be quite 
concerned about the `assumeSafeAppend` performance impact.  I 
think he was not looking for a D1/D2 comparison but in terms of 
getting the most performant behaviour in future.

It's not that it was slower than D1, it's that it was a per-use 
speed hit.

> I spoke for a while with Dicebot at Dconf 2016 or 17 about this 
> issue. IIRC, I suggested either using a custom type or custom 
> runtime. He was not interested in either of these ideas, and it 
> makes sense (large existing code base, didn't want to stray 
> from mainline D).

Yes.  To be fair I think in that context, at that stage of 
transition, that probably made more sense: it was easier to just 
mandate that everybody start putting `assumeSafeAppend` into 
their code (actually we implemented a transitional wrapper, 
`enableStomping`, which was a no-op in D1 and called 
`assumeSafeAppend` in D2).

> By far, the best mechanism to use is a custom type. Not only 
> will that fix this problem as you can implement whatever 
> behavior you want, but you also do not need to call opaque 
> functions for appending either. It should outperform everything 
> you could do in a generic runtime.
>
> Note that this was before (I think) destructor calls were 
> added. The destructor calls are something that assumeSafeAppend 
> is going to do, and won't be done with just setting length to 0.
>
> However, there are other options. We could introduce a druntime 
> configuration option so when this specific situation happens 
> (slice points at start of block and has 0 length), 
> assumeSafeAppend is called automatically on the first append. 
> Jonathan is right that this is not @safe, but it could be an 
> opt-in configuration option.
>
> I don't think configuring specific arrays makes a lot of sense, 
> as this would require yet another optional bit that would have 
> to be checked and allocated for all arrays.

The druntime option does sound interesting, although I'm leery 
about the idea of creating 2 different language behaviours.