Performance - reduce urljoin/urldefrag overhead #202
Conversation
…g by keeping fragments separated from URL (and avoid redunant frag/defrag). Conflicts: jsonschema/tests/test_benchmarks.py issue python-jsonschema#158: Use try-finally to ensure resolver scopes_stack empty when iteration breaks (no detectable performance penalty). * Replace non-python-2.6 DefragResult with named-tuple. * Add test-case checking scopes_stack empty. Conflicts: jsonschema/tests/test_validators.py jsonschema/validators.py
| Awesome, definitely helps, I'll give a shot at looking this over. I mentioned in the other ticket I would want to maintain backwards compatibility for APIs even if they're not used internally anymore, I haven't checked carefully but I expect that to be fairly easy to add back for this subset? A benchmark, even a simplistic one, would also be lovely for anything performance related if possible. |
Cool, I believe the only thing that was removed was
I was using a very simple one myself to profile the changes, so I it should be no problem to include it. I actually have another branch which uses a cache around some of the slower operations and is showing another significant performance increase ontop of these changes. I'll see about getting all of these changes together into a single PR. |
| I've restored Using the example schemas in the bench.py docstring, master: ~56ms I'm going to experiment more with the caching branch. |
| With caching this is down to ~21ms. I'm going to get that branch cleaned up and replace this review I think. |
| A great thank you @dnephin for getting up to this! |
| Definitely, appreciated. Running your benchmark on a warmed up PyPy basically yields equivalent times on my machine, which means this doesn't really speed up anything there (probably expectedly). I'm generally OK with CPython-only speed improvements (which I assume is where you're seeing improvement) as long as it doesn't slow down things on PyPy or introduce other complexity, so seems like we're on the right track here. I'll play a bit more with this until you've got your caching branch as well, this is small enough for me to have a shot at reviewing right now :) |
| Fair point, I wouldn't expect to see much improvement in pypy. I've opened #203 since I rebased over a bunch of these smaller commits. |
3 participants
Based on the work in #182 (I cherry-picked a few commits) for issue #158. Also happens to fix the problem described in #201 at the same time.
Rebased on master, fixed tests and style checks.
Removed base_uri since it was not really being used now that there is a stack.
I hope this is a smaller chunk to review.