Release 0.44.0

[Dentosal]

Version v0.44.0

Changed

• #653: ECAL opcode handler can now hold internal state.
• #657: Add debugger methods to remove or replace all breakpoints at once.

Breaking

• #654: Make public types versionable by making non-exhaustive.
• #658: Make key!-generated types like Address, AssetId, ContractId and Bytes32 consume one less byte when serialized with a binary serde serializer like postcard.

What's Changed

• Add state to ECAL handler by @Dentosal in Add state to ECAL handler #653
• Make public types versionable by @MitchTurner in Make public types versionable #654
• Add batch changes to breakpoints by @Dentosal in Add batch changes to breakpoints #657
• Omit extra byte from types like AssetId when serialized with postcard by @Dentosal in Omit extra byte from types like AssetId when serialized with postcard #658
• Release 0.44.0 by @Dentosal in Release 0.44.0 #659

Full Changelog: v0.43.2...v0.44.0

[xgreenx]

Are we sure that the last change to serialization will not make the performance worse? Could you run simple benchmarks, please?=)

Plus we can remove BytesVisitor. Plus there is a bug with bincode serialization into the file, so maybe you also want to fix it=) It is how fix looks locally for BytesVisitor

[Dentosal]

Plus there is a bug with bincode serialization into the file, so maybe you also want to fix it=)

What bug are we talking about? A performance bug?

[xgreenx]

What bug are we talking about? A performance bug?

No, deserialization bug like here but for bincode.
#643

I think the same test with bincode should fail and the change on the screen fixes the issue

[Dentosal]

I ran some benchmarks, and this is a performance regression. Sadly, there seems to be no way to avoid this if we want to get rid of the extra byte on Bytes32 serialization. Discussion here: serde-rs/serde#2120

We can revert here, but that means having to work around the extra byte in places where we'd rather have the performance penalty than the size penalty.

Benchmarks

Before

bincode Bytes32 [31.612 ns 31.707 ns 31.805 ns]
bincode Bytes64 [31.447 ns 31.507 ns 31.565 ns]
postcard Bytes32 [53.944 ns 54.058 ns 54.167 ns]
postcard Bytes64 [53.965 ns 54.094 ns 54.226 ns]

After

bincode Bytes32 [101.29 ns 101.40 ns 101.50 ns]
bincode Bytes64 [100.83 ns 100.88 ns 100.95 ns]
postcard Bytes32 [129.08 ns 130.31 ns 132.18 ns]
postcard Bytes64 [128.27 ns 128.37 ns 128.47 ns]

[Dentosal]

Ok seems like it was a bad nightly version for benchmarking:

cargo 1.77.0-nightly (84976cd69 2024-01-12):

bincode Bytes32 [27.271 ns 27.322 ns 27.364 ns]
bincode Bytes64 [64.619 ns 64.670 ns 64.723 ns]
postcard Bytes32 [118.21 ns 118.27 ns 118.33 ns]
postcard Bytes64 [202.31 ns 202.52 ns 202.74 ns]

cargo 1.75.0 (1d8b05cdd 2023-11-20)

bincode Bytes32 [26.365 ns 26.391 ns 26.417 ns]
bincode Bytes64 [57.750 ns 57.816 ns 57.889 ns]
postcard Bytes32 [110.73 ns 110.92 ns 111.10 ns]
postcard Bytes64 [199.39 ns 199.60 ns 199.81 ns]