Skip to content

[DRAFT] EVM: optimize mkCodeOps, mkOpIxMap for concrete case - #1048

Draft
elopez wants to merge 2 commits into
mainfrom
perf-contract-mk
Draft

[DRAFT] EVM: optimize mkCodeOps, mkOpIxMap for concrete case#1048
elopez wants to merge 2 commits into
mainfrom
perf-contract-mk

Conversation

@elopez

@elopez elopez commented Mar 9, 2026

Copy link
Copy Markdown
Collaborator

Description

This is showing >20% improvement on contract deployment heavy workloads like contractCreationMem but I need to give it more thought to see if it's truly equivalent, so I'm posting as draft.

Checklist

  • tested locally
  • added automated tests
  • updated the docs
  • updated the changelog

elopez added 2 commits March 9, 2026 10:20
Add mkConcreteOps that works directly on ByteString without the
intermediate [Expr Byte] list. The previous code did BS.unpack (allocates
cons cell per byte) then LitByte <$> (wraps each in Expr) then
maybeLitByteSimp (unwraps back to Word8) -- a pointless roundtrip.

The new code indexes the ByteString directly and only creates [LitByte]
for push data bytes that readOp actually needs.
Replace the accumulated monadic action chain (m >> write >> write >> ...)
with direct ST writes during ByteString iteration. The old approach
created O(n) closures for the >> chain; the new approach writes directly
to the mutable vector with zero closure allocation.
@elopez elopez changed the title Perf contract mk EVM: optimize mkCodeOps, mkOpIxMap for concrete case Mar 9, 2026
@msooseth msooseth changed the title EVM: optimize mkCodeOps, mkOpIxMap for concrete case [DRAFT] EVM: optimize mkCodeOps, mkOpIxMap for concrete case Jun 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant