On 8/3/21 2:21 PM, jfondren wrote:

buffer = new int[100];
auto buffer2 = buffer;
buffer.length = 50;
buffer.length = 51; // must reallocate
buffer[$-1] = 10;

There is not a reallocation on shrinking of length. Or am I misunderstanding your statement?

-Steve

On Tuesday, 3 August 2021 at 18:34:55 UTC, Steven Schveighoffer wrote:

buffer = new int[100];
auto buffer2 = buffer;
buffer.length = 50;
buffer.length = 51; // must reallocate
buffer[$-1] = 10;

I think you're understanding it but not believing it. Again:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  buffer.length = length; // this is a serious bottleneck
}

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  if (buffer.length < length) {
    buffer.length = length; // this is fine actually
  }
}

The story is that the situation was improved by excluding only those cases that should not have incurred any reallocations. Every single invocation of the bottlenecking ensureHasRoom that should have reallocated would still do so with the fixed ensureHasRoom. So something else was going on.

On Tuesday, 3 August 2021 at 19:04:06 UTC, jfondren wrote:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  buffer.length = length; // this is a serious bottleneck
}

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  if (buffer.length < length) {
    buffer.length = length; // this is fine actually
  }
}

ah. No, I get it: this was probably shrinking and then regrowing buffer.length across separate calls, which would incur reallocations on the regrowth.

On 8/3/21 3:04 PM, jfondren wrote:

buffer = new int[100];
auto buffer2 = buffer;
buffer.length = 50;
buffer.length = 51; // must reallocate
buffer[$-1] = 10;

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
   buffer.length = length; // this is a serious bottleneck
}

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
   if (buffer.length < length) {
     buffer.length = length; // this is fine actually
   }
}

The allocation doesn't happen on the shrinking, it happens on the regrowing.

So e.g. you have:

int[] buf;
ensureHasRoom(buf, 10); // allocates
buf[0 .. 10] = 42;
ensureHasRoom(buf, 5); // does not reallocate in both versions
buf[0 .. 5] = 43;
ensureHasRoom(buf, 10); // Maybe reallocates (see below)
buf[0 .. 10] = 44;

So before Ali made the change, the line to regrow to 10 elements DID reallocate, because now it might stomp on data held elsewhere (the runtime has no way of knowing how many references to the array buffer there are, it just knows how much has been used).

After the change, the shrinking to 5 did not actually set the length to 5, the function left it at 10, so the "regrowing" sets the length from 10 to 10. This means no reallocation on the subsequent length change.

The serious bottleneck is on the growing (unnecessarily), not in the shrinking. Clearly, the code in question can handle a buffer that isn't the exact length, but has at least enough length. Here's how I would write the function (if the buffer had to be the exact length needed):

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  bool shouldAssume = buffer.length > length;
  buffer.length = length;
  if(shouldAssume) buffer.assumeSafeAppend;
}

which would have the same effect (though be slightly less efficient since it would still have to be an opaque call into the runtime, and possibly have to fetch block metadata).

-Steve

On 8/3/21 3:16 PM, jfondren wrote:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  buffer.length = length; // this is a serious bottleneck
}

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
  if (buffer.length < length) {
    buffer.length = length; // this is fine actually
  }
}

Yep, correct! Sorry I didn't see this before I did the other reply.

-Steve

On Tuesday, 3 August 2021 at 19:19:46 UTC, Steven Schveighoffer wrote:

Aye, I had some kind of sleep deprivation mental block on this function getting called repeatedly for the same buffer with different lengths. Imagine, instead, 10k separate buffers and a single call of this function on each with a random length. In this case the reallocating calls would be the same with/without the fix.