-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Benchmarks #39
Comments
I took the These benchmarks compare
|
In general, for vectors that fit on the stack, TinyVec is faster than Vec but slower than SmallVec, which I think is a reasonable expectation. Two cases where it's slower than both are For vectors that require a heap allocation, TinyVec is sometimes much slower than both Vec and SmallVec, which is a little surprising to me, and can perhaps be improved. |
I am also surprised. Still, it's very pleasant to see that there is a performance niche for TinyVec as well as simply a safety based case. |
I used this benchmark, but slightly modified to compare performance from 0.3 and branch from #82
EDIT: the functions that have regressions are the ones, that I did not touch, but still I'm willing to improve them |
This is a good start for 0.4
As I expected, extending from slice or from iterator is now much quicker |
I'm interested in helping out here. As a start, I copied @mbrubeck's benchmarks and massaged them a bit. At the moment I'm only tracking the runtime ratio
It looks like there is a lot of work to do here. I have no idea why
And as I'm making this I'm realizing I really need to propagate criterion's uncertainties to this report, the jitter varies a lot between benchmarks. |
I looked into the
Then after the change in #128 we're down to
|
After some small tweaks to the benchmarks and the changes in #129 we are now at:
I've looked into the from_slice/from_slice_small benchmarks and I couldn't come up with any easy improvements. Hopefully at some point someone is able to do something about |
Update, now with multiple container sizes. Still need some benchmarking with types whose default state is not all zeroes, but even with just this things are now more interesting: Benchmarks
A few things jump out at me:
|
It looks like as of my latest work, Overall I think we're now in a good spot. The benchmarks now clearly point out places where Benchmarks
|
Closed by #150? Or do we want more benchmarks per your original list to close this out? |
oh right, yeah. we can close this. |
It seems like in some cases LLVM is able to make this crate just as fast as using
arrayvec
andsmallvec
, but I sure bet that's not always the case.I'd like someone who is passionate about doing lots of benchmarks to do some comparisons. Maybe there's areas we can improve, maybe there's areas we should just report as being a slower path for our crate.
Also currently there's a very high number of
inline
andinline(always)
attribute usage. Since these types are generic we probably don't need as much of that. Benchmarks comparing an inline vs no-inline version are helpful here as well.Things of interest:
tinyvec
types compared toarrayvec
andsmallvec
types.The text was updated successfully, but these errors were encountered: