A recent PR by @andjo403 has created the
tools_lib, which I think is a good idea. In fact, I'd like to go even further and move all the code that is used for reading profiles into this library (i.e. things like
ProfilingData). That would leave only writing parts (
StringTableBuilder, etc) in the
It would also make it easier to depend on crates.io stuff for the reading/processing stuff because I want to keep the
measureme crate as lean as possible but don't care if
tools_lib and the tools depend on lots of upstream things.
I do think we should change the name of
tools_lib though. Possibly to something that has
measureme in the name.
maybe simply measureme_tools_lib
have also made a PR with the split https://github.com/rust-lang/measureme/pull/83
I just gave a review, thanks @andjo403 !
let's discuss the name for
tools_lib (cc @WG-self-profile )
profile_reader perhaps? (per your earlier comment)
afaict, it has nothing to do with "tools" perse, it's just "I want to read a measureme profile" -- right?
it depends. right now there is flamegraph related code in there (shared by two tools)
I think something with "postprocess(ing)" or "analysis" or something similar in the name captures the role of this crate best (assuming that this crate is where more general purpose post-processing stuff will end up in).
analyzeme then to go with postprocessme but shorter
I don't have strong opinions though
@simulacrum, would you prefer having a very targeted crate just for the reading stuff and a bigger, catch-all "tools_lib"?
probably a catch-all
I don't really care too much for splitting up crates in general
e.g. collector in perf.rlo has like ~300 dependencies today
so there's essentially no advantage to adding or losing a couple :)
analyzeme or postprocessme was good maybe more postpocessme was better
selected analyzeme as all felt ok with it