Comments (10)
This is rather standard practice using jacoco. It adds next to no overhead. Any significant overhead here is only because this project takes 10 seconds to build without the agent and 13 with it. In fact, about 3 seconds on jacoco agent is what I've seen across many larger builds. It isn't significant enough to remove for some intented gain. A lot of people use this agent within CI systems such as jenkins. So every build is expected to run the agent in order to promote to CI. This would be slow if the entire jacoco suite was run which it is not.
with the agent -> 13.399 s
without the agent -> 10.539 s
Am I missing something important here? I had the same concerns at my day job when asked to do this about a year ago in much larger projects. After seeing it added next to no overhead I made the switch. So curious as to why this is seen as a bad thing. Of course, tests can be entirely skipped and this drops to 5 seconds. Seems too quick to matter.
from catch-exception.
Unit tests give quick feedback about state of the project (if tests fail there is probably something wrong) - I want to run them together with code compilation from Maven. Code coverage on the other hand is a little more sophisticated technique and I don't check it after every change. 30% percent overhead on every build is 30%. I know people who like to run build from Maven very often (even when using IDE) and 3 second more to wait every time can be visible.
While every build on CI should use JaCoCo and generate report (with Coveralls or something else) I would like to have an ability to disable JaCoCo on "normal" local build (like mvn test
). Probably it should be disabled by default and enabled on demand locally and always turned on CI server.
from catch-exception.
I agree this adds roughly 30% overhead on this project. Further I believe this project is missing a vital execution step which adds no additional time (jacoco report). I plan for a pull request shortly for that.
Now what I do not firmly believe is that the 30% overhead for jacoco is the same no matter the project. Taking an example project off git ('waffle'), it does not add any extra time at all. My own timing testings last year resulted in a couple of seconds on builds that took 2 minutes and up to 10 minutes on their own merrit. I'd have to run those timing again but sort of expect to match waffle with no overhead currently. Lots has changed in the maven world over last year so I'm sure that has a lot to do with me not picking up differences on those large projects. Have you ran anything outside of this project to get similar timings? I guess I'm not really speaking for this project but curious in general as this applies to other projects I work on very heavily.
from catch-exception.
I haven't used Maven in my projects for ~2 years, but the first time I spotted the issue in my Gradle build for the project building with unit tests about 2 minutes JaCoCo was adding several seconds to every build. I didn't profiled it, but it was probably due to agent and its code instrumentation to catch the method calls. It may vary depending on the project. Nevertheless I prefer to disable not needed operations to get the results a little bit earlier (especially if there are side effects - I assume in Maven it could be done somehow without hacks :) ).
from catch-exception.
For me this is:
with the agent and report -> 16.400 s
without the agent -> 8.576 s
from catch-exception.
Solution to building this quicker. use -T to build modules in parallel.
mvn clean install -T 2.0C
This seems to be a sweet spot. I've got an i7 chip. I tried higher number and got a slightly faster build but essentially at this level it builds in less than 8.5 seconds.
from catch-exception.
@hazendaz Good catch - in Gradle builds I have it enabled by default. Nevertheless it is only a workaround - parallel build without JaCoCo should be even faster :).
from catch-exception.
If jacoco is used for coveralls only, the simplest solution would be to switch to cobertura.
I use it one my project and it works fine without any overhead.
Should I open a pull request to see if coveralls behaves the same?
from catch-exception.
Really see no need. Its seconds we are talking about. Machine dependent of course. Plus cobertura doesn't support jdk8 fully. It still has open issues on that. Might not matter here though since this is really sort of eol if you will on jdk8. Although certainly worth checking out for speed comparisons.
--- Original Message ---
From: "Jan-Hendrik Peters" [email protected]
Sent: February 19, 2015 3:10 PM
To: "Codearte/catch-exception" [email protected]
Cc: "Jeremy Landis" [email protected]
Subject: Re: [catch-exception] JaCoCo agent shouldn't be activated on every build (#4)
If jacoco is used for coveralls only, the simplest solution would be to switch to cobertura.
I use it one my project and it works fine without any overhead.
Should I open a pull request to see if coveralls behaves the same?
Reply to this email directly or view it on GitHub:
#4 (comment)
from catch-exception.
Im closing this without change because branch 2.x took only 7.817 s to fully build project and there is no PR to merge :)
from catch-exception.
Related Issues (19)
- Buid failed on JDK8
- Package change for BDDCatchException? HOT 3
- Add support for Mockito 1.10.9+ HOT 19
- BDD-like assertions don't work with Java 8 HOT 4
- VerifyError on verifyException HOT 3
- Fix compatibility issue with Mockito 1.10.8
- Better integration with AssertJ 2.0 HOT 4
- Catch-Exception 2.0 Ideas HOT 5
- Catch exceptions directly in the expected type HOT 10
- outdated documentation HOT 3
- Coverage status icon 404 HOT 3
- Which Maven dependency should I use? HOT 1
- Fails to forward .call() method properly
- Better error when mocking a final class HOT 1
- NullPointerExceptions after catchException() HOT 2
- Mockito spies call real methods instead of stubs with catchException HOT 2
- Handling runtime exceptions HOT 2
- Consider making repo read only (archived now)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from catch-exception.