Conversation
ctz
force-pushed
the
jbp-memory
branch
2 times, most recently
from
1920a7f to
b4ec164
Compare
djc
left a comment
djc
left a comment
There was a problem hiding this comment.
Looks okay to me? I'm very unfamiliar with this codebase, not sure if there's anything in particular you want me to look for or where I go to look at the results.
|
Yeah, I'm similarly unfamiliar. The version at the head of this PR is the one deployed, so the output is being included in PRs right now. eg, rustls/rustls#2756 (comment) which says, for handshake_tickets_1.2_no_crypto_client:
The first line means: cumulatively over the whole test, there were 960 bytes more heap used, but no additional allocations. That means some allocated structure got bigger. It is not possible to say whether the structure got bigger by 960 bytes, or by (say) 96 bytes but was allocated ten times over the test. The second line says a similar thing, but is a snapshot at the peak heap memory usage. |
|
Uhh, not sure I'm seeing that... 
|
|
Hm, odd. Looking into that. |
|
Seeing it now. Perhaps it gets reset when I push? |
Okay, good stuff! |
This didn't work for memory results, because the "headline" figure only is persisted in the database (to match the assumption that any measure is a f64, whereas memory measurements are more structured than that.) This means force-pushes to PRs will re-run and re-measure the benchmarks, naturally that is slower than _not_ doing that, but also takes about two minutes currently.
Yep. I think I have fixed this, and deployed 294f856 |
2 participants
This passes tests. Manually tested with rustls/rustls#2749