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

[Nathan J. <nr...@gm...>]

After some experimentation we were able to speed up our unit testing
time by setting the fork options on the junit task in ant.

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.)

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.

Nathan Johns



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 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, that every time
> > the cobertura.ser file is touched by a test for instrumentation the
> > entire file is read in, updated and then written back to disk.  This
> > seems to be a hug performance hit when compared to running the test
> > without instrumentation.  (in our case about 6-7 times 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 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 a separate
> > file, and these are all then merged at reporting time.  This would
> > reduce disk access and speed up the testing phase and move some of the
> > overhead to when the reporting is done.
> >
> > I suppose one possibility is to make use of different cobertura.ser
> > files for each module and merge them at the end?  Would appreciate any
> > comments you might have.
> >
> > Nathan Johns
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you s=
hotput
> > a projector? How fast can you ride your desk chair down 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
> >
>