Codecov Report

Merging #719 (0ab4385) into next (977c9e3) will decrease coverage by 0.09%.
The diff coverage is 100.00%.

❗ Current head 0ab4385 differs from pull request most recent head 488b354. Consider uploading reports for the commit 488b354 to get more accurate results

@@            Coverage Diff             @@
##             next     #719      +/-   ##
==========================================
- Coverage   86.42%   86.32%   -0.10%     
==========================================
  Files          51       51              
  Lines        4714     4687      -27     
  Branches     1032     1022      -10     
==========================================
- Hits         4074     4046      -28     
- Misses        455      456       +1     
  Partials      185      185              

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 977c9e3...488b354. Read the comment docs.

@bdice thanks for tackling this! Could you also rerun some of the benchmarks that we looked at in conjunction with #484 to see how much they improve with this applied? IIRC the switch to synced collections increased the cost of converting keys to strings, and that increase was exacerbated because I implemented it as a separate validator (with the expectation that it would be removed), so we should see a marked improvement now.

@vyasr I looked at the benchmarks but there is no apparent change. I believe that this is because we created a single validator json_attr_dict_validator that does all the logic of require_string_key and json_format_validator in a single function. The branch I eliminated from that function was the elif isinstance(key, (int, bool, type(None))):. Since the first if isinstance(key, str): is always hit by the benchmarking code (all keys are strings), I don't think this would result in any performance changes.

@bdice you're right, I forgot that when I implemented that new validator I bypassed the perf issue entirely. I think I initially recognized that the sequence of validators would be slower but wrote it off as a temporary issue until 2.0, but then when you did your much more thorough benchmarking of #484 and we saw how bad it was I just implemented the custom validator to recover performance. So I think we're good here.