git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/8] Support coverage testing with GCC/gcov

From
Thomas Rast <trast@student.ethz.ch>
Date
Feb 19, 2009, 14:11 UTC
Message-ID
<200902191512.16755.trast@student.ethz.ch>
In-Reply-To
<alpine.DEB.1.00.0902191227260.6223@intel-tinevez-2-302>
Johannes Schindelin wrote:
Show 18 quoted lines
> On Thu, 19 Feb 2009, Thomas Rast wrote:
> > I noticed two small things that I'd like to fix before this goes
> > 'next', so here they are:
> > 
> > * [1/8] Support coverage testing with GCC/gcov
> > 
> >   Changed it so the compilation (but not the testing) uses the same -j
> >   flags as the caller, so that compilation can be done in parallel.
> >   (It's rather minor compared to the slow testing with optimizations
> >   turned off, but still.)
> 
> I strongly disagree that it is minor.  _Especially_ since the tests are 
> slow, -j makes a huge difference.
> 
> And also without making the tests slower, -j makes a dramatic difference 
> here:
> 
> 	$ /usr/bin/time make -j50 test
That's not the point.

I agree that for the test suite, -j makes a huge impact, since it takes so long. But even though the docs claim it should be possible, I've been getting "random" test failures when compiled with coverage support, that went away with -j1. So the tests still run with -j1, as with the first version of the series.

However, the first version used a single make invocation for the'all' and 'test' targets, which of course also means that the _compilation_ ('all') happens with -j1. That's not necessary as far as I can see, and I split them into separate commands in v2, where 'all' doesn't pass a -j option any more (so that the caller's choice remains in effect).

What I meant by the above remark is that the maybe 30 seconds you gain by compiling in parallel are a very minor gain when compared to the enormous running time of the _sequential_ test suite _without optimizations_, which feels like 15-20min here, I haven't even timed it. (I always mount t/ on a tmpfs which does away with the fsync() bottleneck and lets me do ordinary test runs, with NO_SVN_TESTS, in under 3min.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Previous: Johannes SchindelinNext: Sverre Rabbelier
Message 18 of 19 in “What's cooking in git.git (Feb 2009, #06; Wed, 18)”
  1. Junio C HamanoFeb 19, 2009
  2. 0/8 Support coverage testing with GCC/gcovThomas Rast, Feb 19, 2009
  3. 1/8 Support coverage testing with GCC/gcovThomas Rast, Feb 19, 2009
  4. 2/8 Test that diff can read from stdinThomas Rast, Feb 19, 2009
  5. 3/8 Test diff --dirstat functionalityThomas Rast, Feb 19, 2009
  6. 4/8 Test log --graphThomas Rast, Feb 19, 2009
  7. 5/8 Test fsck a bit harderThomas Rast, Feb 19, 2009
  8. Test fsck a bit harderThomas Rast, Feb 20, 2009
  9. Johannes SixtFeb 20, 2009
  10. Test fsck a bit harderThomas Rast, Feb 21, 2009
  11. Johannes SixtFeb 21, 2009
  12. Test fsck a bit harderThomas Rast, Mar 1, 2009
  13. Junio C HamanoMar 3, 2009
  14. 6/8 Test log --decorateThomas Rast, Feb 19, 2009
  15. 7/8 Test rev-list --parents/--childrenThomas Rast, Feb 19, 2009
  16. 8/8 Test git-patch-idThomas Rast, Feb 19, 2009
  17. Johannes SchindelinFeb 19, 2009
  18. Thomas RastFeb 19, 2009
  19. Sverre RabbelierFeb 19, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.