Chatting w/ jam@ and rockot@

They said that if we want to make sure we reuse the shared memory, the only way is to use a shared buffer. and that data pipe is basically a shared buffer w/ signaling, so it wouldn't be any faster.

(context: this only effects the case where there are multiple large items with files in between (ipc max,500mb), and there are multiple in between files)

So the other option here is to change requesting as data pipe to requesting population of a shared memory segment that we re-use w/ items.

Unclear which is going to be simpler to write.

Apologies, applied the wrong component in bulk.

Setting Internals>Services>Storage to all children of issue 611935

this doesn't block canary.

not related to network service.

mek@: does this seem to be a useful feature?

No idea how bad the overhead is of creating new shared memory regions over and over. Probably in the general case not much. So I guess the main thing here is if at some point we do decide to replace data pipes with some other mechanism built on top of other mojo primitives (which I think was the proposed solution whenever the suggestion to add new functionality to data pipes is brought up) this might be something to keep in mind.

OK, thanks. I'm gonna close this then. I think two things are true:

1. We do ton of shared memory allocation all over the place, and I am not aware of any evidence that this is a performance issue.

2. The ship has pretty much sailed on leaving data pipe in the low-level Mojo API as a first-class primitive.

So I'd say if a situation comes up where we're actually impacted by allocation performance then this concern would naturally arise again. For now I'd rather clear it from the backlog.