PFS performance - Check flame graph for easy optimizations

[karlb]

I've profiled the PFS while running the BF4 scenario against it, yielding the following flame graph: flame_bf4.svg.gz

Is there anything that's taking obviously too long? Any simple perf improvements we can do?

[hackaugusto]

Log formatting is also a problem for the PFS, 6.56% of the time is spent in the logging inside get_paths. Most of this time is spent in the to_checksum_address function. On _handle_message the computation of sender seems to be done twice, resulting is a wasted 3% of the time. For some reason requests is calling a function merge_environment_settings which seems very slow on all paths. Also in requests, it looks like url validation done by requests.sessions.prepare_request is very slow. And the last thing that seems slow is web3's formatters that don't have tail call recursion optimization.

All-in-all it looks like most of our problems are in third-party libraries. The time spent in the database and the graph search, which are the most important pieces of the whole server, are negligible ... but something is very off, I didn't see any sleeps in the flamegraph. It may indicate a bug in the profiling code.

[Dominik1999]

• optimize event_abi_to_log_topic becaus 5.77% of the time is spent here save up to ~40% of time by batching of event polling
• finalize https://github.com/raiden-network/raiden/pull/5003 in Raiden
• batch event polling like in Raiden here https://github.com/raiden-network/raiden/pull/5003
• remove extra checks from web3 of the addresse's checksum

[palango]

We should profile this again with the latest version