perf: possible mem leak in v8.serialize()

[ppedziwiatr]

Issue raised by Pianity.
In some environments the rss memory usage grows to very large values (it does not happen on my M1 though).
This is probably related to nodejs/node#40828

Removing the v8's serialization (https://github.com/redstone-finance/redstone-smartcontracts/pull/84/files#diff-5acab41990585fa68ae01ff7b2e2915628d19237840c3061b31fcadc1c0f09b8) fixed the memory leak issues, but at a cost of performance - therefore a better solution needs to be developed.

[ppedziwiatr]

switch to https://developer.mozilla.org/en-US/docs/Web/API/structuredClone when it will be implemented by most of the browsers.

[balthazar]

👍🏻 Subscribing

[ppedziwiatr]

Performance comparison ("state evaluation" column) for "loot" contract:

1. @ungap/structured-clone

2. v8.deserialize(v8.serialize(input))

3. lodash/cloneDeep

4. JSON.parse(JSON.stringify(input, mapReplacer), mapReviver);

[balthazar]

Maybe I'm not reading the bench correctly, but isn't lodash more performant than ungap here?

[ppedziwiatr]

Maybe I'm not reading the bench correctly, but isn't lodash more performant than ungap here?

You're reading the bench correctly ;-) lodash indeed is more performant than ungap and v8 in this case. Though I believe that for "bigger" states - v8 was the winner. Anyway, I'll stick with lodash for now...

[ppedziwiatr]

Just a word of comment if anyone was interested - deepCopy-ing of the state is required for each interaction - before the state is passed to the contract's handler function. Contracts usually modify the state directly and without deepCopy - there would be risk of changing values somewhere in the host code (eg. values stored in cache).

v1 performed here simple stringify/parse https://github.com/ArweaveTeam/SmartWeave/blame/master/src/contract-step.ts#L56 - which obv. is least performant.

This won't be an issue in case of WASM contract - which store their state in the wasm module memory.

[ppedziwiatr]

fixed in #108, released in 0.4.36

[balthazar]

Ah ok, I was confused with the commits being referenced using ungap, but they were probably old

🎉 Will try this