onflow / developer-grants

Grants for developers that contribute to the broader developer ecosystem
Apache License 2.0
50 stars 18 forks source link

Cadence Profiler #178

Open m-Peter opened 1 year ago

m-Peter commented 1 year ago

Cadence Profiler for Smart Contracts / Scripts / Transactions

Grant category

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:

Proposed solution

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

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. markoupetr@gmail.com m_peter
sideninja commented 1 year ago

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

turbolent commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

joshuahannan commented 1 year ago

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 commented 1 year ago

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

bluesign commented 1 year ago

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 commented 1 year ago

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.

sideninja commented 1 year ago

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.