search

aigeano / pympler

Automatically exported from code.google.com/p/pympler
Apache License 2.0
0 stars 0 forks source link

Runtime for setup.py try and test #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Trying Pympler and running the tests can take a variable amount of time.  One 
example, on my Intel 
Mac (1.9 GHz Core Duo, 2 GB RAM) they take about 78 seconds but on my PowerPC 
Mac (400 MHz 
G4, 512 MB RAM) it is much longer, 560 secs.

We should make a note in the README file or in the release notes that ... "the 
time to run the tests 
varies anywhere from about one minute to as much as 10 minutes, depending on 
your platform".

Original issue reported on code.google.com by MrJean1@gmail.com on 30 Nov 2008 at 7:36

GoogleCodeExporter commented 9 years ago

Original comment by MrJean1@gmail.com on 30 Nov 2008 at 7:51

GoogleCodeExporter commented 9 years ago 
Most of the time is spent in this, one test:  test_otracker_diff 
(muppy.test_tracker.TrackerTest)

Original comment by MrJean1@gmail.com on 30 Nov 2008 at 8:03

GoogleCodeExporter commented 9 years ago

Original comment by MrJean1@gmail.com on 30 Nov 2008 at 8:11

GoogleCodeExporter commented 9 years ago 
We had a similar problem before. AFAICT, the test may be affected by other 
objects in
memory when the test is run. The last time we had the problem, switching off the
garbage collector and not reactivating it in the Heapmonitor test led to severe
runtime problems in the TrackerTest.

That is one of the drawbacks of combining all tests into a single test suite 
(distant
effect). (If only the above mentioned test is run, the problem should 
disappear.)

Original comment by lhae...@gmail.com on 30 Nov 2008 at 10:05

GoogleCodeExporter commented 9 years ago 
Perhaps we should run that one, long test first or only during development or 
make it shorter.

Original comment by MrJean1@gmail.com on 1 Dec 2008 at 12:51

GoogleCodeExporter commented 9 years ago 
I would follow Jean's suggestion and disable this test, at least for the 
release.
There is probably no clean way to do this, so if we follow this path, just 
comment
the test and file an issue assigned to me.

Original comment by robert.s...@gmail.com on 4 Dec 2008 at 6:27

GoogleCodeExporter commented 9 years ago 
I added a hack in r239 which makes sure muppy tests are run first. The runtime 
should
be predictable and stay sane. The right way to do this would be to sandbox the 
test,
but this would take more work. If you want to disable the test instead, go for 
it.

Original comment by lhae...@gmail.com on 22 Nov 2009 at 12:52