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.
