Analyzing several ExecutionDataStores separately in the least expensive way

[André Silva]

Hi,

We are the JaCoCo API through offline instrumentation to obtain class
coverages for each executed test method.

Right now, we perform a full analysis of each ExecutionDataStore
obtained after the run is finished and resetting it for the next one.
This works, but as we increase the number of runs it quickly becomes
very time consuming.

Now, as far as I understood, JaCoCo doesn't provide a way of passing
several ExecutionDataStore to the Analyzer and performing class/method
analysis of all at once. Parallelization by itself doesn't yield enough
of a speedup.

To achieve this I can only think of a big refactor of
org.jacoco.core.internal.flow and andorg.jacoco.core.internal.analysis
packages, so that the Analyzer takes a set of ExecutionDataStores and it
propagates this information.

Am I missing something?

Best regards,
André 

[Marc Hoffmann]

Hi,

I don’t understand your requirement.

> Now, as far as I understood, JaCoCo doesn't provide a way of passing
> several ExecutionDataStore to the Analyzer and performing class/method
> analysis of all at once.

What exactly should be the outcome? A single IBundleCoverage or a separate one for every execution date?

In the first case you can merge execution data and then do analysis just once. In the latter case indeed you have to do analysis for every execution data.

If you assume that code and your test cases grow both with the same rate the problem has quadratic complexity, regardless how you refactor the code.

Cheers,
-marc

> --
> You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jacoco+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/430c7b9f-6e25-5c77-d67f-8cf7a2ffe2a5%40kth.se.

[André Silva]

Hi,

The expected outcome is a separate one for every execution.

Yes, it will always be quadratic indeed.

Is there any way of limiting the analysis to classes where at least one probe was activated? As far as I understand right now all classes are analyzed regardless of whether any line in them was executed. Is this correct?

Cheers,
André

[Marc Hoffmann]

Hi André,

Is there any way of limiting the analysis to classes where at least one probe was activated?

That might be possible:

- Create and index in the class files by JaCoCo class id

- Only process the classes of the class ids in the respective execution data 

As far as I understand right now all classes are analyzed regardless of whether any line in them was executed. Is this correct?

Correct. Because you typically want to see the overall coverage and not ignore untested classes.

Cheers,

-marc 

To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/5dc8d04e-d81b-4cad-b24e-9060e2326b7cn%40googlegroups.com.

[André Silva]

Hi Mark,

I have opened a PR on Jacoco related to our discussion here.

See https://github.com/jacoco/jacoco/pull/1212

Best,
André

You received this message because you are subscribed to a topic in the Google Groups "JaCoCo and EclEmma Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jacoco/r30tcRU2VVg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jacoco+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/B8AE25A6-3BAF-4524-9D54-636AB7EB8378%40mountainminds.com.