Fix loading of charmap from cache file

[robertknight]

Loading the cached charmap from disk always failed because the
GzipFile was passed to json.loads, which expects a string. Use
json.load instead, which accepts a file.

This fixes an issue where the first test in a test run that used the
charmap would be unexpectedly slow.

For context, see #2108 (comment).

[Zac-HD]

Wow, that's a pretty serious bug! Thanks heaps for spotting it, and the PR! (with tests 😍)

You'll need to add a release file (with thank-you note) and I'd encourage you to add yourself to the list of authors too. See #2162 for a good example of what this looks like.

[robertknight]

You'll need to add a release file (with thank-you note) and I'd encourage you to add yourself to the list of authors too. See #2162 for a good example of what this looks like.

Done. Thanks for the help :)

[Zac-HD]

Thanks again Robert 🎉

[Zac-HD]

https://travis-ci.org/HypothesisWorks/hypothesis/jobs/605943000#L759-L765

[robertknight]

I'm looking into the test failure on Travis. I have a related question though about whether we could potentially just bundle a precompiled version of the charmap in the Hypothesis package, along with a script to regenerate it? The only time it changes AFAIK is when new Unicode versions are released.

On CI systems, each new branch (or sometimes every build) typically starts out with a fresh build directory, so the first test that triggers a call to charmap() will result in a call to this function. The caching therefore doesn't help many builds by default. The flaky test failure in our app's test suite that brought the issue to light was:

E   hypothesis.errors.FailedHealthCheck: Data generation is extremely slow: Only produced 6 valid examples in 1.35 seconds (0 invalid ones and 2 exceeded maximum size). Try decreasing size of the data you're generating (with e.g.max_size or max_leaves parameters).
E   See https://hypothesis.readthedocs.io/en/latest/healthchecks.html for more information about this. If you want to disable just this health check, add HealthCheck.too_slow to the suppress_health_check settings for this test.

[Zac-HD]

We have considered shipping this as a static data file, but the way that e.g. unicode version can vary by platform makes it fairly tricky to be sure that everything stays in sync (not that the status quo is perfect, either...). Given that we want to address the 'long delay on first run' for other reasons too, we're likely to go with a more general solution.

[robertknight]

Hmm, the linux-py35 tests are failing. I'll look into that.

Given that we want to address the 'long delay on first run' for other reasons too, we're likely to go with a more general solution.

OK. I had a look at optimizing the existing cache generation and was able to find wins of ~2x by reducing the number of hash lookups: https://gist.github.com/robertknight/055d19c61c5dbe2c1169a54e1da7f238.