Technical Working Group: Scalability & Performance

@johan couldn’t join the session, so we had a free discussion on stable memory on the IC.

Updated Meeting Notes and Recording.

1 Like

We’ll skip this week’s Scalability & Performance WG. I already wish you a nice Christmas and see you all in January.


I’d like to follow-up on this question. Will multiple memories do anything that would make stable structures unnecessary?

To specify my question more, will it be possible to create a native data structure (like a Rust struct) and simply tell it which memory to use during instantiation of the data structure? And could one or more memories be set aside as stable, so that we could actually have native stable data structures instead of having to create specialized (and a bit limited) stable data structures?

I’m imagining the main Wasm heap could maintain pointers to native structures in the stable memories, and perhaps on upgrade those pointers can be collected and stored in a stable memory, and then restored to their variables after upgrade.

Is this just crazy talk? @johan @rossberg

1 Like

The memory layout of a native data structure is not guaranteed to be stable or backwards compatible. In theory, even if the developer uses the same compiler binary with the same source code, the compiler is still allowed to use a different memory layout of native data structures based on non-deterministic optimizations.

While multi-memories enable fast access to the stable memory, the developer still needs to ensure that data stored in the stable memory is stable and backwards compatible.


Hey everybody,

Tomorrow 01/19 at 5:30pm CET we’ll have the first WG session of 2023.

The main topic for tomorrow will be a discussion on:

Canister queues (ingress, input and output) overview and case studies of handling large message volumes

led by @dsarlis.

Looking forward to see many of you!


Unfortunately I could not attend this meeting for family reasons. Would you happen to have a recording to share @domwoe please ?

1 Like

The meeting is actually scheduled for today the 19th (I guess Dominic made a typo on the date that no one noticed :sweat_smile:).

1 Like

Oopsie, fixed.

In any case, I always record and share.


Updated meeting notes and recording.


Will the recording be uploaded to youtube? Zoom player acting buggy on my side

1 Like

hmm, we haven’t uploaded WG sessions to Youtube thus far. I don’t think there’s a particular blocker but the audience is pretty small at the moment.


This would be a great bounty for someone to pursue while exploring these patterns at the library level. Pipelineify already handles a lot of this queuing action, and it would likely need to use some of the libraries that would help with managing input output queues.

1 Like

I remember reading about throughput limitations of BTC transactions, but can’t find it. Something like one transaction per block per subnet. Does anyone know the actual number and whether there is ongoing work to increase it?

Found it:

1 Like

To clarify: the limit you point to is the current throughput of tECDSA signatures per second that a subnet can produce (you need those in order to submit BTC transactions so of course the limit on those sort of implies a limit on the BTC transactions themselves).

AFAIK, the current implementation of tECDSA is not super optimized, so I would expect that this limit can be increased eventually. Likely there is going to be some limit on what a single subnet can do (the protocol is quite complex) but there is always the possibility to allow more subnets to sign using tECDSA which means we can “scale out” the throughput of these operations on the IC as whole.


Hey everybody,

we’ll be moving this week’s session to next week same time:

Thursday, February 23rd 5:30pm CET (GMT+1).

I’ve already updated the calendar.

We’ll have another session on using storage on the IC. We’ll prepare a survey that we’ll share before the session and want to discuss the results in the session.

Sorry for the late notice and I hope many of you can join nevertheless.


Hey everybody :wave:,

In preparation for the WG session this week, we’d like to invite you to take a quick survey on how you use memory on the IC:

Please participate and join the WG on Thursday where we’d like to discuss the results. :pray:


Hey everybody :wave:,

The Working Group is happening in about 40 mins (5:30pm GMT+1).

We’ll discuss the results of the survey and @senior.joinu will give an update on on the ic-stable-memory rust library.

See you soon!


Belated update:

slides with the responses from the survey and the recording.

Some topics from the discussion:

If you watch the recording and have thoughts please feel free to add them here.


We have also a request to move the working group from Thursdays at 5:30 pm CET (GMT+1) to Wednesdays at 6:30 pm CET (GMT+1). Are there any objections to that? Note that we’d still use the cadance of every 3rd Wednesday of a month.

@lastmjs @dymayday @skilesare @senior.joinu @icme @dsarlis @claudio @abk @stefan-kaestle @saikatdas0790


Hey @domwoe, will the move to 18:30 permanent ?
Sorry for being late on the mater but I feel it is kinda late as it is the time dedicated to the kids for me.

I really enjoy this working group and I don’t want to sounds selfish though. This is why I’m asking if this is the permanent schedule from the on.