This commit adds a tsm1 function for encoding a batch of floats into a
buffer. Further, it replaces the `bitstream` library used in the
existing encoders (and all the current decoders) with inlined bit
expressions within the encoder, significantly reducing the function call
overhead for larger batches.
The following benchmarks compare the performance of the existing
iterator based encoders, and the new batch oriented encoders. They look
at a sequential input slice and a randomly generated input slice.
name old time/op new time/op delta
EncodeFloats/10_seq 1.14µs ± 3% 0.24µs ± 3% -78.94% (p=0.000 n=10+10)
EncodeFloats/10_ran 1.69µs ± 2% 0.21µs ± 3% -87.43% (p=0.000 n=10+10)
EncodeFloats/100_seq 7.07µs ± 1% 1.72µs ± 1% -75.62% (p=0.000 n=7+9)
EncodeFloats/100_ran 15.8µs ± 4% 1.8µs ± 1% -88.60% (p=0.000 n=10+9)
EncodeFloats/1000_seq 50.2µs ± 3% 16.2µs ± 2% -67.66% (p=0.000 n=10+10)
EncodeFloats/1000_ran 174µs ± 2% 16µs ± 2% -90.77% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
EncodeFloats/10_seq 0.00B 0.00B ~ (all equal)
EncodeFloats/10_ran 0.00B 0.00B ~ (all equal)
EncodeFloats/100_seq 0.00B 0.00B ~ (all equal)
EncodeFloats/100_ran 0.00B 0.00B ~ (all equal)
EncodeFloats/1000_seq 0.00B 0.00B ~ (all equal)
EncodeFloats/1000_ran 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
EncodeFloats/10_seq 0.00 0.00 ~ (all equal)
EncodeFloats/10_ran 0.00 0.00 ~ (all equal)
EncodeFloats/100_seq 0.00 0.00 ~ (all equal)
EncodeFloats/100_ran 0.00 0.00 ~ (all equal)
EncodeFloats/1000_seq 0.00 0.00 ~ (all equal)
EncodeFloats/1000_ran 0.00 0.00 ~ (all equal)
While debugging, I was printing out some structs with %#v and found that
Go would format the structs' IDs as uint64s instead of with the String
method. That behavior needlessly made my debugging more difficult.
Before, %#v would format a type with an ID like:
{ID:0x2def021097c6000}
After:
{ID:"02def021097c6000"}
They look similar, but a search for the string ID would not match the
uint64 default formatting.
This keeps file compatability by just writing out zeros for the
sizes and offsets. Perhaps it's ok to just nuke everything and
remove the data.
It also keeps the hll package because it seems generally useful
even if it's not currently being used.
What happened here is kind of a long story.
The TaskService tests exercise different parts of the TaskService
concurrently, in hopes of exercising code that may be racy. This worked
fine so long as we were able to use arbitrary user and organization IDs
picked during test.
Then we added tests for the http-client-backed TaskService. The instance
of http.TaskService takes a single token, so the TaskService tests were
updated to use an optional override to get the user and org ID from the
TaskService implementation.
That meant our parallel tests were using one user and org ID in some
cases. One particular test to exercise concurrency would create tasks
and then retrieve them and delete one. Because this test was filtering
by user and org, sometimes it would delete a task created in a different
test.
The fix was to maintain a whitelist of tasks created in that particular
test, so that it wouldn't delete tasks created in a different test.
This also adjusts the TaskService interface's RetryRun method to accept
a task ID rather than an org ID. Internally, we still look up runs by
organization, and maybe that will change later, but this is a more
natural way for clients to look it up.
Edd Robinson
Adam
Mark Rushakoff
Jeff Wendling
kelwang
Chris Goller
zhulongcheng
Kelvin Wang
Nathaniel Cook
Jeff Wendling
Brandon Farmer
Stuart Carnie
Michael Desa
Christopher M. Wolff
Jade McGough
Jorge Landivar
jlapacik