Rationale: same as for useless_vec, as in 01cb7ee0a1.
Prompted by reading a commit where someone did makework to get rid of
an occurrence of this warning.
We need a type that holds a rend_handshake::IntroRequest object
internally, but where we don't materialize that object from the
Introduce2 message inside the MsgHandler, since that's more crypto
than we want to put in that task.
The hsdir selection algorithm for uploads and downloads is different
enough to justify splitting `hs_dirs` into 2 different functions.
More specifically, when selecting the relays to upload a service's
descriptors to, the service's `hsids` need to be matched up with the
correct `ring` (using the time period) before applying `select_nodes` to
pick the replicas. This is not the case when downloading, because
for downloads select relays from the current ring.
This duplicates some code from hsclient as noted in the comments;
it might be good to reduce this, but the remaining nontrivial
duplication is small, and the logic flow is slightly different
because of the two-step process.
This is a very small change that converts our Vec cheaply into a boxed
slice during program generation. Program generation speed shows no
changes, and there's no change when using compiled hashes, but is a
surprisingly effective 10% speedup to interpreted hash execution.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
I was looking for ways to optimize out the many redundant capacity
checks in the Assembler. I didn't find any promising approaches, but
I also saw no evidence that it was an important bottleneck. (A simple
unsafe fix didn't improve any important metrics)
While I was in there, I tightened up the buffer size definitions for
both x86_64 and aarch64, and added assertions to test the limits we
set for the size of prologue, epilogue, and single instructions.
I kept some of the inlining and data type tweaks, even though benchmarks
show no difference. They seem like a step in the right direction, from
the disassembly at least.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
This is a very simple change that avoids a surprising performance
pitfall: using the code() method on an enum from another crate
caused a non-inlined function call in code where we otherwise expect
a high level of compiler optimization. Replacing code() with a cast
to u8 avoids this function call and allows more intensive optimization
at the call site.
Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>