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

[Sinke, M. \(GE Healthcare\) <mar...@me...>]

As a testimony: this cut down our build/test times (the entire cycle)
from around 24 to 20 minutes. A 15%+ saving just by setting the flag!

Thanks!

Mark.=20

__ =20

"From there to here,
from here to there,
funny things are everywhere."
        - One Fish, Two Fish, Red Fish, Blue Fish, Dr. Seuss
  _____ =20

Mark J. Sinke
Senior Software Architect/Patient Directory Team Lead
GE Healthcare Information Technologies
Clinical Information Technologies Core Infrastructure Platforms=20

T +31 30 692 6000
F +31 30 692 6010
D *381 6446
E mar...@me... <mailto:mar...@me...> =20

www.gehealthcare.com <http://www.gehealthcare.com>=20


-----Original Message-----
From: cob...@li...
[mailto:cob...@li...] On Behalf Of Mark
Doliner
Sent: Thursday, June 16, 2005 20:22
To: Nathan Johns; Grzegorz Lukasik
Cc: cob...@li...
Subject: RE: [Cobertura-devel] Performance Issues - cobertura.ser

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...]
> 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=20
> 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=20
> separate JVM:
> <junit fork=3D"true" haltonfailure=3D"true">....
> But no one realised this was forking a new JVM for each test when we=20
> 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=20
> when the instrumentation data was read and written, now they all run=20
> very quickly and this overhead occurs once for each fork.  (For us=20
> that is once for each module.)
>=20
> Thanks for the pointers in resolving this...  one of those little=20
> quirks of Ant and the junit task.  I still think there may be=20
> something to consider in what I originally said about appending data=20
> but I suppose you can achieve the same affect, with the forkmode=20
> option, using a different cobertura.ser file for each module and then=20
> 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=20
> > ProjectData.getOrCreateClassData method, and additionaly=20
> > ClassData.touch implementation. Both these methods are invoked each=20
> > 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=20
> > > 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=20
> > > 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 shotput
> > > 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=20
> > > _______________________________________________
> > > Cobertura-devel mailing list
> > > Cob...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> > >
> >
>=20


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
_______________________________________________
Cobertura-devel mailing list
Cob...@li...
https://lists.sourceforge.net/lists/listinfo/cobertura-devel