PVF worker: look into removing unneeded dependencies

[mrcnski]

ISSUE

Overview

As part of #882, we want to block unneeded syscalls in the PVF workers. After #650 we will have separate worker binaries, whose object files we can analyze for included syscalls. However, right now a lot of unnecessary syscalls are found present in the object files.

This issue is about removing some big dependencies¹ and seeing if it has an impact on syscalls or binary size, or if Rust is smart enough that it's already optimizing as much as it can. (Will make sure to try this in combination with enabling LTO.)

Footnotes

1. i.e. we can remove the dependency on polkadot-node-core-pvf by moving that into e.g. host and common objects into common, so we have the following structure: pvf/host, pvf/worker, pvf/common. Then see how that affects binary size. ↩

[mrcnski]

Auditing the dependencies, it looks like we can almost get rid of tokio, which would be a big win here, except that tracing-gum uses tokio heavily.

Since tracing-gum itself is a heavy dependency it would be nice to replace it, without actually removing logging altogether. Maybe we can send all logs back to the host over the socket, and have the host log them?¹

And/or we can have simple text logs specific to the workers. cc @sandreim

Footnotes

1. It wouldn't work for the threads (which don't do any logging right now anyway, and probably shouldn't), since we want to sandbox them and block socket calls. ↩

[sandreim]

How much of a win is getting rid of tracing dependency in this case ? What is the cost of a replacement ? I agree that tracing-gum is not really needed here.

[mrcnski]

Don't have exact numbers, but tracing-gum seems to pull in quite a lot of dependencies when I run cargo tree -e normal, including networking (?). Getting rid of it and tokio would probably reduce the file size significantly and reduce the syscalls found in the binary. I plan to get some hard numbers once I get around to this issue.

What is the cost of a replacement ?

If we send logs over a socket, then the cost is just another socket I suppose. Alternatively we could reuse the same socket and use a prefix to detect if the message from the worker is a log or a response.

[slumber]

How much of a win is getting rid of tracing dependency in this case ? What is the cost of a replacement ? I agree that tracing-gum is not really needed here.

tracing-gum depends on jaeger, and it's quite heavy https://github.com/paritytech/polkadot/blob/master/node/jaeger/Cargo.toml

[bkchr]

The dependency on jaeger is just one function, that could just be copied.