Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upDocument all the performance #16301
Comments
Gankro
referenced this issue
Aug 6, 2014
Closed
add discussion of performance analysis to libcollection #16267
cmr
added
A-rustdoc
labels
Aug 6, 2014
This comment has been minimized.
This comment has been minimized.
|
Well, while we are dreaming big… It would be amazing to automatically validate performance properties (to some extend) using #[bench(time O(log n), space O(1))]
fn bench_something(b: &mut Bencher) {
b.iter_with_size(|n| {
perform_magic!(n)
});
}This would of course require (a) a structure where one can easily generate large examples and (b) benching various sized (Combine this with a code generator, quickcheck and a small datacenter and you might never need computer science again!) |
This comment has been minimized.
This comment has been minimized.
|
@killercup I don't think the relation between asymptotic and real performance is well-defined enough to permit such functionality. Especially in the face of expected and amortized behaviors. Even |
thestinger
referenced this issue
Sep 19, 2014
Closed
Containers tutorial should include performance characteristics for maps and sets #9849
This comment has been minimized.
This comment has been minimized.
|
I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized. This issue has been moved to the RFCs repo: rust-lang/rfcs#636 |
Gankro commentedAug 6, 2014
This is, I guess, a metabug.
As I discuss in #16267, I believe that libcollections should provide both high-level asymptotic performance as well as practical performance guidelines (e.g.
Vec.pushis faster thanRingBuf.pushandDList.pushfor most workloads) for all relevant functions and methods.The biggest open question in my mind is whether performance should be indistinguishable from regular documentation, or take on a special form that Rustdoc can manipulate. For instance, perf docs could be prefixed by
//?or placed in an annotation like[#perf-time(O(1) amor.)]. The former would need further special syntax to differentiate time/space information, the latter would need some augmentation to permit extended discussion.Regardless of the form it takes, making this available to Rustdoc would allow some cool stuff like Traits including a performance table for their implementers. See Qt's Algorithmic Complexity section for an example of what these tables might look like.
I would also suggest we adopt the following notation conventions, or something similar: