Replace testify package

[cmasone-attic]

Summarizing discussion and history:

We use https://github.com/stretchr/testify extensively, both in unit tests and at runtime (for assertions) and have had lots of perf problems with it over the months, mostly due to its use of reflection.

We should just replace this with a simpler version that doesn't use reflection. We don't need that capability, either for our tests or anything else.

In our dbg package, we created a struct that wraps stretchr/testify/assert so we can do things like Chk.Equal() -- analogous to CHECK_EQ() from the Chromium world.

The stretchr stuff is meant to be used in tests, so it's not particularly performant; specifically, the Equal() predicate does reflection to determine if the two things you pass it are comparable. In some of our hot code paths, this adds a lot of runtime -- calling it in ref.Ref.Less() added 15% overhead or so in our initial xml_importer code. It seems to be related not only to the time spent in reflection, but also triggering a fair amount of garbage collection.

We tried creating a Chk.NaiveEqual() predicate that just took whatever you passed it and compared them using !=, but this proved to only save about half the time vs. comparing the values directly and passing the result to Chk.True().

[aboodman]

Now that we have forked testify, we should just add a SimpleEqual method.

[aboodman]

One can find the callsites to be fixed like so:

git grep 'd.Chk.True' | grep '=='

[aboodman]

Hm, actually, per @cmasone-attic's last sentence, it looks like our only option might be d.Chk.True(). This should be re-checked on modern Go though, as the situation seems like it could have changed.

[aboodman]

Also, d.Chk.Nil/and d.Chk.NotNil have same problem because they use reflection.

[aboodman]

On #1727, @rafael-atticlabs said:

"The problem is that those calls require interfaces and reflection in order to not need one for every type."

@rafael-atticlabs, as part of #1727, did you check whether the interfaces alone are a problem (in exclusion of reflection)? Several Go versions ago Chris checked and reported in this bug that they were still expensive, but it's hard for me to understand why they are that expensive (Go interfaces don't require boxing heap-based AFAIK).

Obviously, everything is relative, but yes: Interfaces are both expensive and appear to be boxing. That's part of my optimism that we can make blob chunking go so much faster. A large part of the profile now is convT2E and convE2T which, as I understand it, are the runtime converting between a concrete type and an interface (and back). Collectively, those represent a large part of the allocations.

[aboodman]

huh. looks like my mental model was based on theoretical future work, not actual current behavior:

golang/go#8618

:(

[aboodman]

This has been subsumed by #1964 - new idea is to allow testify in test, but not production.

[aboodman]

On second thought I would still like to do this. Testify has too much magic, it's too easy to misuse. See #7 in particular.

I want to get rid of the part of testify that allows you to pass in two interface{} and they magically get compared. That's the bit that is easy to break.