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

Speed up the framework #171

Open
jribbink opened this issue Aug 18, 2022 · 2 comments
Open

Speed up the framework #171

jribbink opened this issue Aug 18, 2022 · 2 comments

Comments

@jribbink
Copy link
Contributor

jribbink commented Aug 18, 2022

Instructions

Make the testing framework faster so that Jest timeouts don't need to be so long.

Issue To Be Solved

The testing framework can be quite slow with complex tests (exceeding 10 seconds long). This can cause discrepancy between local testing and CI runners confusing developers.

(Optional): Suggest A Solution

There are a few ways which emulator performance can potentially be optimized.

  1. Use a WASM version of the flow-emulator. This would allow direct interfacing with the emulator via Javascript, remove slowdowns related to spawning a new process. (and it would be a cleaner way of operating this library, which is always a plus). Prototyping has shown WASM to be significantly slower than native and this does not appear to be a solution.

  2. Find a better way of deploying FlowManager. Currently, multiple transactions and scripts are involved in checking if FlowManager is deployed/deploying it at any point of execution which causes some slowdown. While this would likely have lower latency if the emulator was built through WebAssembly, it is still an inefficient means of completing this task.

    Whether through WASM or not, there should be some efficient means of deploying the FlowManager contract invariably when Flow JS Testing starts up (avoiding constantly checking if it has already been deployed).

(Optional): Context

An example of this is on the flow-nft repo. The tests in this commit https://github.com/onflow/flow-nft/tree/a8674860f8f6cb2c441532a5ff9051d8176fcda8 will pass on a M1 Macbook but fail on the CI runner. This discrepancy can be somewhat troubling for the end user and potentially hard to debug.

See GH actions log: https://github.com/onflow/flow-nft/runs/7903285241?check_suite_focus=true

@bluesign
Copy link

bluesign commented Oct 4, 2022

Oh I was just gonna create issue on this.

Problem is not the emulator. Recently I ran kitty items tests on my M1 MacBook.

Initially was something like this:

Kitty Items
     should deploy KittyItems contract (3631 ms)
     supply should be 0 after contract is deployed (3700 ms)
     should be able to mint a kitty item (4168 ms)
     should be able to create a new empty NFT Collection (3918 ms)
     should not be able to withdraw an NFT that doesn't exist in a collection (4579 ms)
    ✓ should be able to withdraw an NFT and deposit to another accounts collection (4807 ms)

There are some sleeps ( 2 sec for total, 1 second each for emulator start and stop there ) But still the numbers were huge.

I debugged the problem, it is signing the transaction part. If you use new emulator option --skip-tx-validation, and just give some dummy signature ( any hex string with 128 length, 64 byte signature x 2 digits )

Final result is :

 PASS  ./kitty-items.test.js
  Kitty Items
     should deploy KittyItems contract (504 ms)
     supply should be 0 after contract is deployed (514 ms)
     should be able to mint a kitty item (634 ms)
     should be able to create a new empty NFT Collection (625 ms)
     should not be able to withdraw an NFT that doesn't exist in a collection (774 ms)
    ✓ should be able to withdraw an NFT and deposit to another accounts collection (796 ms)

Also I have some plans for multi tenant emulator, I think it can be good for your use case. ( onflow/flow-emulator#207 ) @jribbink

@bluesign
Copy link

bluesign commented Oct 4, 2022

with NFT tests:

 PASS  tests/nft_forwarding_test.test.js (6.329 s)
  NFTForwarding Contract Tests
     Should forward NFT to designated forwarding recipient (1353 ms)
     Setup then change forwarding recipient (1236 ms)
     Setup NFTForwarder then unlink recipient's collection. Forwarding should fail. (1239 ms)
    ✓ Setup NFTForwarder then unlink and restore collection in forwarder's account (1242 ms)

 PASS  tests/nft_test.test.js
  NonFungibleToken Contract Tests
     Should have properly initialized fields after deployment (659 ms)
     Should be able to mint a token (746 ms)

Test Suites: 2 passed, 2 total
Tests:       6 passed, 6 total
Snapshots:   0 total
Time:        8.647 s, estimated 9 s

PS: I also had some retry issue on http-transport here

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

No branches or pull requests

2 participants