Cadence Profiler

[m-Peter]

Cadence Profiler for Smart Contracts / Scripts / Transactions

Grant category

• [x] Developer tools / services
• [x] Open source maintenance

Description

Cadence is the native programming language for developing smart contracts / scripts / transactions that run on the Flow Blockchain. The Flow Emulator displays profiling data in logs about scripts and transactions, including computationUsed and memoryEstimate (this one is currently being added by our team, https://github.com/onflow/flow-emulator/pull/366). These logs, however, are not enough to drill down and get to the source of the bottleneck that is causing execution issues, due to high execution efforts. Hence, I would like to implement a Cadence Profiler, to enable Flow builders to build more robust smart contracts.

Problem statement

When designing smart contracts, one important concern is their performance and ability to scale. In some cases, after a period of time, the smart contract and some of its APIs, might become unwieldy due to their growth in computation & memory usage. This means that developers will not be able to run certain scripts / transactions, as they will reach the maximum execution limit. One such case can be seen here:

• https://github.com/onflow/nft-catalog/issues/138
• https://discord.com/channels/613813861610684416/811693600403357706/1090726294683131966

Proposed solution

Make use of the existing code that calculates the computation & memory used

• https://github.com/onflow/flow-go/blob/master/fvm/environment/meter.go
• https://github.com/onflow/cadence/blob/master/runtime/common/metering.go

and expose these metrics in a readable & accessible format to developers, through the Flow Emulator / Flow CLI.

Impact

Developers will be able to understand why scripts & transactions need a certain amount of computation & memory to run, and in turn they would be able to optimize their contracts.

Milestones and funding

Milestone	Deliverables	Timeline	Risks	USD proposal
1 - Emulator API for ProfilingReport	Create a new Emulator API to display a ProfilingReport including all scripts / transactions	~ 4 weeks	-	7,500
2 - Detailed ProfilingReport for contracts	Break down of computation/memory used by each statement on a contract	~ 8 weeks	-	15,000
3 - Adoption	Use the profiler on at least 5 contracts	~ 2 weeks	-	1,000/contract
4 - Miscellaneous	Add documentation and usage examples. Raise awareness in relevant channels and promote the practice of profiling through technical articles and blogs	~ 2 weeks	-	1,000

Total Cost: 28,500 USD. Of course, I am open to discussion, regarding the cost and timeline :slightly_smiling_face: .

Team

Name	Role	Bio	Contact
Ardit Marku	Back-end Engineer	A seasoned back-end engineer with a focus on problem solving and designing robust software systems. Over 8 years of experience building high-traffic search engines, marketplaces, exchanges and in-house analytics solutions. Led cross-functional teams to deliver both web and mobile apps, participating in all steps of the software development lifecycle. Open source lover and advocate.	[email protected] m_peter

[devbugging]

I really like this proposal. It will be super useful for understanding Cadence execution.

[turbolent]

Thank you for opening this proposal @m-Peter!

We are currently in the process of publishing more developer grants for Cadence and related tooling, guided by importance and impact for the ecosystem, and are planning to get back to reviewing this proposal afterwards. Thank you for your patience

[m-Peter]

Thanks for the heads up @turbolent :bow: Let me know if I can be of any help, regarding the upcoming developer grants for Cadence. I would like to tackle some of the important needs of the ecosystem, and make an impact :pray:

[m-Peter]

@franklywatson Since this https://github.com/onflow/flow-emulator/issues/388 is gonna be solved soon, is there any positive sentiment from the Flow team for this grant to proceed?

[joshuahannan]

I'm definitely in support of this. It would be super useful for me and many others in the ecosystem!

[joshuahannan]

I just want to make sure this will also be able to estimate gas usage because that really is the metric that most developers care about because they need to know what to set their gas limit at

[m-Peter]

@joshuahannan That makes total sense, I will experiment locally, how to calculate the gas for scripts & transactions :pray:

[bluesign]

I think this computation tracking per statement is amazing feature too. If we can integrate with tools like code-coverage (like @m-Peter did before perfectly), it can make things a bit more predictable.

[m-Peter]

Yes, the end goal would to be get general execution metadata, including things like line hits, computation and memory usage. So instead of just coverage report that we have under the Emulator endpoint (http://localhost:8080/emulator/codeCoverage), we could have a unified report with execution metadata.

[devbugging]

Yes, the end goal would to be get general execution metadata, including things like line hits, computation and memory usage. So instead of just coverage report that we have under the Emulator endpoint (http://localhost:8080/emulator/codeCoverage), we could have a unified report with execution metadata.

This is awesome! I can't wait for this to get integrated into tools.