polkadot VS py-spy

Polkadot (6400 GitHub Stars) https://github.com/paritytech/polkadot

I don't think asynchronous backing has any direct effect on the number of parachains, no (I mean, there likely is an effect, but it's not the goal and my understanding is that any effect on that would be minimal, although I'm not involved in the deep engineering here). It increases throughput, correct, by decreasing the time between blocks by not needing to do a "roundtrip" to the relay chain to build new blocks. See https://github.com/paritytech/polkadot/issues/3779 for an overview.

Specifically, it was this PR that changed it: https://github.com/paritytech/polkadot/pull/6230

A particular validator sent out a LOT of dispute reports (i.e., saying that other validators did something incorrectly) last night (for reasons unknown). It looks like other nodes "choked" reading all of these disputes, and one subsystem died, stalling nodes but NOT killing the process. It's still being investigated, but you can look at the issue on Github to see it being discussed here: https://github.com/paritytech/polkadot/issues/6412

Asynchronous backing- This might sound a bit dry, but it means that parachains can have increased throughput and double block production speed.

# Clone the Polkadot Repository, with correct version git clone --depth 1 --branch release-v0.9.24 https://github.com/paritytech/polkadot.git # Switch into the Polkadot directory cd polkadot # Build the relay chain Node cargo b -r

An entirely new and more decentralized form of governance - see https://github.com/paritytech/polkadot/pull/5205

This is obviously a very high-level description! For more detail, I recommend reading Gav's description in the Medium post here: https://medium.com/polkadot-network/xcm-the-cross-consensus-message-format-3b77b1373392 or if you really want to dig in, you can review the code here: https://github.com/paritytech/polkadot/tree/59aa955576e963942c60e3ae8f8316444b66cafb/xcm

otherwise this should be the github repository of parity, maybe you can find something there as well? https://github.com/paritytech/polkadot

https://github.com/benfred/py-spy is also really nice, and has an actual oss license.

For CPU cycles, py-spy[0] is getting more and more used. For RAM, I would like to known too...

[0] -- https://github.com/benfred/py-spy

Theres also Py Spy, a profiling tool that can generate flame charts containing a mix of python and C (or C++) calls.

https://github.com/benfred/py-spy

It's worked really well for my needs

You should profile your consumer to check the bottlenecks. You can use the excellent py-spy(written in Rust). IMO a few usage of Numba there and there should solve your performance issues.

Any advantages/disadvantages compared to py-spy [1]?

[1]: https://github.com/benfred/py-spy

Python profiling is enabled primarily through cprofile, and can be visualized with help of tools like snakeviz (output flame graph can look like this). There are also memory profilers like memray which does in-depth traces, or sampling profilers like py-spy.

Might be worth raising an issue on py-spy (a python profiler written in rust which "supports profiling native python extensions written in languages like C/C++ or Cython" to see if that can close the loop.

It is pretty cool. py-spy has also been doing this for a few years

https://github.com/benfred/py-spy