>> Maybe later, Rust-simpletrace and python-simpletrace can differ, e.g. >> the former goes for performance and the latter for scalability. > > Rewriting an existing, maintained component without buy-in from the > maintainers is risky. Mads is the maintainer of simpletrace.py and I am > the overall tracing maintainer. While the performance improvement is > nice, I'm a skeptical about the need for this and wonder whether thought > was put into how simpletrace should evolve. > > There are disadvantages to maintaining multiple implementations: > - File format changes need to be coordinated across implementations to > prevent compatibility issues. In other words, changing the > trace-events format becomes harder and discourages future work. > - Multiple implementations makes life harder for users because they need > to decide between implementations and understand the trade-offs. > - There is more maintenance overall. > > I think we should have a single simpletrace implementation to avoid > these issues. The Python implementation is more convenient for > user-written trace analysis scripts. The Rust implementation has better > performance (although I'm not aware of efforts to improve the Python > implementation's performance, so who knows). > > I'm ambivalent about why a reimplementation is necessary. What I would > like to see first is the TCG binary tracing functionality. Find the > limits of the Python simpletrace implementation and then it will be > clear whether a Rust reimplementation makes sense. > > If Mads agrees, I am happy with a Rust reimplementation, but please > demonstrate why a reimplementation is necessary first. > > Stefan
I didn't want to shoot down the idea, since it seemed like somebody had a plan with GSoC. But I actually agree, that I'm not quite convinced. I think I'd need to see some data that showed the Python version is inadequate. I know Python is not the fastest, but is it so prohibitively slow, that we cannot make the TCG analysis? I'm not saying it can't be true, but it'd be nice to see it demonstrated before making decisions. Because, as you point out, there's a lot of downsides to having two versions. So the benefits have to clearly outweigh the additional work. I have a lot of other questions, but let's maybe start with the core idea first. — Mads Ynddal
