Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entity serialization is slow #1134

Closed
Jannis opened this issue Aug 26, 2019 · 2 comments · Fixed by #1145
Closed

Entity serialization is slow #1134

Jannis opened this issue Aug 26, 2019 · 2 comments · Fixed by #1145
Assignees

Comments

@Jannis
Copy link
Contributor

Jannis commented Aug 26, 2019

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

store.get / Entity.load are currently slow because serializing even simple entities by allocating and writing to WASM memory is implemented in an inefficient way. We tracked this down to AscHeap::asc_new / AscHeap::raw_new causing a lot of small memory allocations, each of which take ~3-5ms. For a reasonably sized entity, this ends up at around 20-40 allocations and 150-200ms (locally, debug build).

What is likely taking so long under the hood is memory.grow() calls inside wasmi.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

Clone and deploy any subgraph that uses Entity.load and follow the logs. You should see Store get messages that are fast, but Done processing Ethereum event messages that indicate the handler takes a long time (~500-1500ms):

Aug 24 20:20:25.758 DEBG Store get finished, time: 1ms, id: 0xd4fd252d7d2c9479a8d616f510eac6243b5dddf9, type: Account, block_hash: 0x3669b543ae19ed0a56c50f80f66e67d6dc3004e62bc3d848ecc2b95b42d253ee, block_number: 4161317, subgraph_id: Qmd1WDLn9QzX8tJYJyYh8AdCCjqqg3oqE8fDs4bQyjad7d, component: SubgraphInstanceManager
Aug 24 20:20:25.845 DEBG Store get finished, time: 3ms, id: 0xd4fd252d7d2c9479a8d616f510eac6243b5dddf9-0xe41d2489571d322189246dafa5ebde1f4699f498, type: AccountBalance, block_hash: 0x3669b543ae19ed0a56c50f80f66e67d6dc3004e62bc3d848ecc2b95b42d253ee, block_number: 4161317, subgraph_id: Qmd1WDLn9QzX8tJYJyYh8AdCCjqqg3oqE8fDs4bQyjad7d, component: SubgraphInstanceManager
Aug 24 20:20:26.101 INFO Done processing Ethereum event, waiting_ms: 0, total_ms: 1331, handler: handleTransfer, signature: Transfer(indexed address,indexed address,uint256), block_hash: 0x3669b543ae19ed0a56c50f80f66e67d6dc3004e62bc3d848ecc2b95b42d253ee, block_number: 4161317, subgraph_id: Qmd1WDLn9QzX8tJYJyYh8AdCCjqqg3oqE8fDs4bQyjad7d, component: SubgraphInstanceManager

What is the expected behavior?

The expected behavior is that each handler takes only a few milliseconds, even with store.get / Entity.load involved. The serialization of an entity to WASM should ideally only take <5ms overall.

@MaxGraey
Copy link

MaxGraey commented Aug 27, 2019

Also you could try this PR which improve detection when memory.grow should call

@leoyvens
Copy link
Collaborator

@MaxGraey thanks for the pointer, right now we're on a pre-runtime version of AS and upgrading won't be easy because we write objects in the AS memory format. We're hoping to get WASM Interface Types before upgrading again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants