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

Improve Smart Testing Performance #236

Open
dipak-pawar opened this issue Oct 18, 2017 · 10 comments
Open

Improve Smart Testing Performance #236

dipak-pawar opened this issue Oct 18, 2017 · 10 comments

Comments

@dipak-pawar
Copy link
Contributor

dipak-pawar commented Oct 18, 2017

  • Run Smart-Testing with any real project.
  • Find all areas which impacts execution time/performance using profiling.
  • After finding all areas, find optimized solutions for it.
@MatousJobanek
Copy link
Contributor

I have one idea how to improve the performance:
The calculations (scm) would be executed in a separated thread, so the main thread wouldn't be blocked and could continue with the Maven build. I guess that calculation should be probably finished before the surefire execution starts (in most of the cases), but this has to be managed anyway (in cases when it takes more time than the compilation etc...).
To avoid the state when the surefire starts before the calculation is finished and tries to read non-existing or uncomplete scm-changes file, the logic should use some marker. This marker can be a temporary empty file that would represent that the execution is still being processed. When the calculation execution is finished, the file is removed. On the surefire side, this file would be checked if whether still exists or not. If not, then it can start looking/reading the scm-changes file and continue with normal test execution.

@lordofthejars
Copy link
Member

Yes it is a good idea, even we could create some kind of chain on this. For example when scm changes has been calculated, if affected strategy is enabled, start calculating graph too. But maybe this is something to take into consideration as next step.

@MatousJobanek
Copy link
Contributor

@lordofthejars IIRC you have some big project with a lot of test classes. Is it AssertJ or something else?

@MatousJobanek
Copy link
Contributor

if affected strategy is enabled

If we don't want to detect which strategies are activated in the maven extension phase, then we cannot create this kind of chain.
Instead of chaining the strategy specific tasks, we could introduce another level of optimization - running the activated strategy implementations in parallel.

@lordofthejars
Copy link
Member

Yes it was just assertj

@bartoszmajsak
Copy link
Member

@lordofthejars can you share modified project so we can have a simple reference to reproducer?

@lordofthejars
Copy link
Member

There were no modification, I just cloned the assertj project and modified org.assertj.core.util.Strings_join_Test with one redundant test

@bartoszmajsak
Copy link
Member

And how did you execute the build? Which version of ST was defined in extensions.xml?

@lordofthejars
Copy link
Member

In the git history of workshop you can see next things if you want to reproduce exactly the same thing:

You need to run this using affected strategy and it is where the 2 million nodes are created.

You need to run this using changed strategy, but no performance issues observed at that time.

@bartoszmajsak
Copy link
Member

Thanks, that's exactly the context we will need when we dive into this analysis!

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

No branches or pull requests

4 participants