-
-
Notifications
You must be signed in to change notification settings - Fork 590
The latest version is slower than 3.2.0 validator #1231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I understand part of the code. The reason why it is slower than the old version is that the verification items are constantly increasing. I am currently using Draft202012Validator. After switching to Draft4Validator, the difference is doubled (the original difference was five times). dont know if it is like this |
I don't know what you're meaning to report with this issue. 4.3.1 is a very old version, and 3.2.0 is an ancient one. If you're trying to report any issue, you need to include a minimal working example of what you ran and what the change was. |
for the old version (4.0.1) I just want to speed up the execution to be close to version 3.2.0 (or older), because the latest version is slower than version 4.3.1 (as per issue #853 first (the result of running a test case)), I gave up this version and came here to ask for advice. |
Slower on what? #853 is a very old issue about a very old version. The current version of this library is 4.21.1, which is the only version I support. |
Ok, I see. Thanks. I've found the solution. The new version does not have this problem, and the efficiency has returned to that of the ancient version. |
I would like to ask if I can replace 'for error in self.evolve(schema=schema).iter_errors(instance, schema)' in version 4.3.1: This line is 'for error in self.iter_errors(instance, schema)' in version 3.2.0 :, I found that this can reduce 2-3 seconds when traversing 500 times;
In addition, my current version is 4.0.1, just replace the 'find_item' in the 'resolve_fragment' method with find.
The text was updated successfully, but these errors were encountered: