Skip to content
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

Performance enhancement for larger API jsons #33

Open
Vity01 opened this issue Jul 1, 2020 · 0 comments
Open

Performance enhancement for larger API jsons #33

Vity01 opened this issue Jul 1, 2020 · 0 comments

Comments

@Vity01
Copy link

Vity01 commented Jul 1, 2020

At this time the whole check runs in a single thread. For larger API jsons (300+ paths) processing takes a while.
Simple math: 300paths * count of breaking changes checks. It does not scale much.
The processing can be launched in parallel
In DefaultBreakChecker
return rules.stream().map(rule -> rule.checkRule(oldApi, newApi)).flatMap(Collection::stream).collect(toList());

with just a replacement of stream() into parallelStream() it runs faster...
Unfortunately it has some possible side effects. The order of result list of breaking changes is unpredictable - that can be confusing for user. Therefore I also suggest to add a support for BreakingChange priority and to sort the result list by this value. Eg. PathRemoval breaking change can have higher order priority than others.

Also I am not sure about implementation of classes SeenRefHolder, SchemaStoreProvider which they are using ThreadLocal.

There are also other possible places for speed improvements. Eg. loading old and new api can be launched in parallel as well. With Project reactor it can be a piece of cake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant