RE: [Cobertura-devel] Performance Issues - cobertura.ser

[Mark D. <Mar...@sa...>]

Thanks for the info.  It DOES look like forkmode is a new option in ant =
1.6.2.  I'm not sure if earlier versions used "once" or "perTest"

In any case, I added a small blurb about that to
http://cobertura.sourceforge.net/anttaskreference.html

-Mark=20

> -----Original Message-----
> From: Nathan Johns [mailto:nr...@gm...]=20
> Sent: Wednesday, June 15, 2005 6:05 PM
> To: Mark Doliner; Grzegorz Lukasik
> Cc: cob...@li...
> Subject: Re: [Cobertura-devel] Performance Issues - cobertura.ser
>=20
> After some experimentation we were able to speed up our unit testing
> time by setting the fork options on the junit task in ant.
>=20
> Previously when the build was setup we required Junit to fork into a
> separate JVM:
> <junit fork=3D"true" haltonfailure=3D"true">....
> But no one realised this was forking a new JVM for each test when we
> upgraded to Ant 1.6.2. (Not sure if this was the case for Ant 1.5)  So
> have now changed the build scripts to:
> <junit fork=3D"true" forkmode=3D"once" haltonfailure=3D"true">....
> And the speed improvement in the unit testing phase is amazing.=20
> Previously Each test seemed to have an overhead of 4 to 5 seconds for
> when the instrumentation data was read and written, now they all run
> very quickly and this overhead occurs once for each fork.  (For us
> that is once for each module.)
>=20
> Thanks for the pointers in resolving this...  one of those little
> quirks of Ant and the junit task.  I still think there may be
> something to consider in what I originally said about appending data
> but I suppose you can achieve the same affect, with the forkmode
> option, using a different cobertura.ser file for each module and then
> merging them at the end.
>=20
> Nathan Johns
>=20
>=20
>=20
> On 6/16/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > The problem here may be implemetation of
> > ProjectData.getOrCreateClassData method, and additionaly
> > ClassData.touch implementation. Both these methods are invoked each
> > time "line of code" is executed. Both methods get/put some=20
> information
> > from maps. The result is that with each line of code some operations
> > that are in most cases many times more expensive are executed.
> >=20
> > Grzegorz
> >=20
> > On 6/10/05, Nathan Johns <nr...@gm...> wrote:
> > > Hi,
> > >
> > > It appears to me, though I haven't looked at the code,=20
> that every time
> > > the cobertura.ser file is touched by a test for=20
> instrumentation the
> > > entire file is read in, updated and then written back to=20
> disk.  This
> > > seems to be a hug performance hit when compared to=20
> running the test
> > > without instrumentation.  (in our case about 6-7 times=20
> slower, on a
> > > build that take 15 minutes without instrumentation this makes it a
> > > very long build cycle.)
> > >
> > > Would it perhaps make more sense to append=20
> instrumentation data to the
> > > cobertura.ser file (may need to be done a different way if
> > > cobertura.ser is a serialized object(s)) and then process all this
> > > data at reporting time to aggregate it into class statistics?
> > >
> > > In other words for each test, when it reads in cobertura.ser and
> > > writes it, it creates its own data either appended or in=20
> a separate
> > > file, and these are all then merged at reporting time.  This would
> > > reduce disk access and speed up the testing phase and=20
> move some of the
> > > overhead to when the reporting is done.
> > >
> > > I suppose one possibility is to make use of different=20
> cobertura.ser
> > > files for each module and merge them at the end?  Would=20
> appreciate any
> > > comments you might have.
> > >
> > > Nathan Johns
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by: NEC IT Guy Games.  How=20
> far can you shotput
> > > a projector? How fast can you ride your desk chair down=20
> the office luge track?
> > > If you want to score the big prize, get to know the little guy.
> > > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
> > > _______________________________________________
> > > Cobertura-devel mailing list
> > > Cob...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> > >
> >
>=20