Performance regression between 1.88.0 and 1.89.0 about nautilus_trader

[dkharrat]

No, I haven't used use_pyo3 logging. I haven't changed the code. I'm only changing the Nautilus version.

I'm loading both 1-min bar and 5-min bar data, since my strategy subscribes to 5-min bars. The 1-min bars helps with producing more accurate fills.

I did observe something related to that that might provides some clues:

• When loading only 1-min bar data, and having the strategy subscribe to 1-min bars, the performance on both 1.88.0 and 1.89.0 is similar (around ~30 secs).
• Also, loading only 5-min bar data and having the strategy subscribe to 5-min bars, the performance on both 1.88.0 and 1.89.0 is similar. (around ~6 secs)
• However, loading both 1-min and 5-min bar data and having the strategy subscribe to 5-min bars, that's when the performance is different. (~9 secs in 1.88.0 and ~33 secs in 1.89.0).

Did something change related to how bars are loaded or processed?

[cjdsellers]

Hi @dkharrat

I can't see anything obvious so far, did you start using the use_pyo3 logging option by any chance?

I generally run some of the example backtests periodically and can't see any significant performance change, I wonder if this might be specific to bars in some way?

[cjdsellers]

Hey @dkharrat

Thanks for going through this and providing the extra information. There's a chance this could have something to do with a change to how the message bus processes published messages (including bars), but I'll have to test.

[cjdsellers]

So after a lengthy investigation this was tracked down to a subtle edge case with the MessageBus topic resolving.

The issue

A bug was fixed for the 1.189.0 release whereby it became possible to subscribe to topics which previously had messages published with no subscribers.

This change caused a performance regression where messages being published without any subscribers would always go through an expensive topic/pattern resolving operation.

The fix

Now fixed from d28da76 with a simple boolean flag.

Whenever subscribe or unsubscribe is called on the bus, its put back into an "unresolved" state until the next message is published with has no subscribers. There is still an edge case existing where multiple of these "no subscriber topics" could need resolving (and only the first one will resolve), however this at least fixes the most common use case and performance regression.

Let me know if this fix works for you when you get a chance.