This is one of the reasons I'd like to move over to jUnit 4.x. EMF initialization / cleanup could be done in @BeforeClass / @AfterClass methods. The catch is the using jUnit 4 uses around 4x the heap space. I'm not sure whether this is a result of using jUnit 4 to run jUnit 3 tests, or whether it would be the case if we converted the entire bucket though.
Making the EMF static in SingleEMFTC should have the same effect, but I haven't had a chance to try it out.. -mike On Mon, May 11, 2009 at 11:28 AM, Pinaki Poddar <[email protected]> wrote: > > Hi, > One more way to speed up is to reduce initialization cost. > SingleEMFTestCase does not really lives up to its name, meaning for a > TestCase we are not using a single EMF but for each method EMF is getting > initialized. That has a upfront cost in terms of schema definition. Most of > the test cases, however, can work with a single EMF for all its individual > testXXX() methods. > > > allee8285 wrote: > > > > Donald, > > > > I shall take a look tomorrow and see what can be done to shorten the > > duration. > > > > > > On Thu, May 7, 2009 at 8:54 PM, Donald Woods <[email protected]> wrote: > > > >> Just ran a compile+test with loglevel=TRACE on openjpa-persistence-jdbc > >> using Rev762563 on April 6 (which included the lockmgr additions on > April > >> 5) > >> and it took 51 mins, so it looks like the lockmgr tests are the cause of > >> the > >> almost 100% increase in time to run the junit tests..... > >> > >> Albert, can we somehow reduce the scope of these tests? > >> > >> > >> -Donald > >> > >> > >> > >> Donald Woods wrote: > >> > >>> Tried rebuilding Rev760056 from March 30 (after the OPENJPA-5 changes > >>> for > >>> JDK6) and it took 25 mins. for compile+test of openjpa-persistence-jdbc > >>> with > >>> loglevel=TRACE, so still looking.... > >>> > >>> -Donald > >>> > >>> > >>> Donald Woods wrote: > >>> > >>>> Yep, I'm stuck trying to add the derby.locks timeouts, as the lockmgr > >>>> tests need a waitTimeout > 20 seconds (haven't determined exact number > >>>> as > >>>> the tests dynamically determine their wait time based on the speed of > >>>> the > >>>> system....) > >>>> > >>>> Just went back and looked at a trunk build I still had from March 24 > >>>> and > >>>> the compile + test run for all the trunk modules took 27 mins. on my > >>>> Mac, > >>>> versus 51 mins. now.... :-( > >>>> > >>>> > >>>> -Donald > >>>> > >>>> > >>>> Miłosz Tylenda wrote: > >>>> > >>>>> I have also noticed this. I don't think the metamodel and criteria > >>>>> stuff > >>>>> is the cause. I suspect we test a lot of method call permutations and > >>>>> the > >>>>> tests are mainly waiting for deadlock or timeout. I am also in favor > >>>>> of > >>>>> trying to reduce the time. Maybe not all premutations are needed or > >>>>> query > >>>>> timeouts may be set to some lower value. > >>>>> > >>>>> Greetings, > >>>>> Milosz > >>>>> > >>>>> Just noticed in the past week or so that the > openjpa-persistence-jdbc > >>>>>> bucket went from taking about 30 mins. to run for me under JDK5 on > my > >>>>>> Mac > >>>>>> (Core 2 Duo @ 2.5GHz) to around 45 mins. now (and same results on > >>>>>> WinXP).... > >>>>>> Anyone else noticed this? > >>>>>> > >>>>>> So, I dug into the openjpa-persistence-jdbc results and noticed that > >>>>>> the lockmgr tests are taking about 26 mins. of that time to run by > >>>>>> just > >>>>>> executing that subset of tests - > >>>>>> mvn -o test -Dtest=org.apache.openjpa.persistence.lockmgr.* > >>>>>> -Dopenjpa.loglevel=TRACE > >>>>>> > >>>>>> Looking at the run times - > >>>>>> > org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerRefreshPermutation > >>>>>> takes 15 mins. to run > >>>>>> > org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerLockPermutation > >>>>>> takes 4.2 mins. to run > >>>>>> > org.apache.openjpa.persistence.lockmgr.TestMixedLockManagerFindPermutation > >>>>>> takes 4.2 mins. to run > >>>>>> > >>>>>> Has there been any relevant changes introduced by the recent > >>>>>> metamodel > >>>>>> or criteria work that could have affected the tests like this? > >>>>>> > >>>>>> If not, is there anyway we can reduce the amount of time or number > of > >>>>>> tests we run for lockmgr testing? Seems that we have included way > >>>>>> too many > >>>>>> tests (creates/deletes around 678 threads during the tests) for a > >>>>>> simple > >>>>>> unit test goal and most of these could be moved to a SVT bucket.... > >>>>>> > >>>>>> > >>>>>> -Donald > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > > > > > > -- > > Albert Lee. > > > > > > > ----- > Pinaki Poddar http://ppoddar.blogspot.com/ > > http://www.linkedin.com/in/pinakipoddar > OpenJPA PMC Member/Committer > JPA Expert Group Member > -- > View this message in context: > http://n2.nabble.com/Junit-tests-taking-longer-to-run-on-trunk--tp2836004p2863995.html > Sent from the OpenJPA Developers mailing list archive at Nabble.com. > >
