[Bug] Session object instantiation is very slow

[yellowhatter]

Describe the bug

It takes ~10 seconds to create 10 Sessions sequentially. It is too much, especially for some tests.

To reproduce

Create 10 Sessions sequentially with async or sync API.

System info

• Platform: Ubuntu 22.04
• CPU: AMD Ryzen 5000 series
• Zenoh ef2555f653a8f101f5fe7c9b0972eae77a9c1a80

[Mallets]

Can you please provide a code snippet on how you create the session?

[yellowhatter]

Here is a test.

#[test]
fn session_perf() {
    let many_sessions: Vec<Session> = (0..10).map(|_| zenoh::open(zenoh::config::peer()).res_sync().unwrap() ).collect();
    assert!(many_sessions.len() == 10);
}

It takes 8 seconds to run it on my machine. res_async() API shows the same performance.

[Mallets]

Thanks!

@OlivierHecart: could the initial delay be related to scouting?

[OlivierHecart]

What we have today are:

1. A configurable scouting_delay (default: 200ms) which goal is to make sure we discovered local peers before starting operating.
2. A build-time configurable API_OPEN_SESSION_DELAY (default: 500ms) which goal is to make sure we discovered remote subscribers and queryables before applying writer side filtering.

Those delays add up to 7 seconds for 10 sessions.

The new interest protocol should allow to remove the API_OPEN_SESSION_DELAY. Still the scouting_delay should remain in peer mode.

[yellowhatter]

What about pre-initializing discovery data from already existing sessions when creating a new one? - if this would be possible, we could also avoid awaiting for scouting_delay.

[Mallets]

What about pre-initializing discovery data from already existing sessions when creating a new one? - if this would be possible, we could also avoid awaiting for scouting_delay.

I believe that creating so many sessions is useful mainly for testing purpose, I wouldn't expect the user to create that many. Generally, the user will interact with only one Zenoh session. In case of having different session, I'm expecting the users to do so by using different configurations for each session. If that's the case, then mutualizing discovery data can be very tricky. Are the different sessions discovering the same thing? Is it really the same system?

Long story short, if the scouting_delay is not acceptable in testing, why not avoiding scouting and setting the endpoints manually? Like here? Would that be an option?