-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just installing 2.6rc2, I see that bsddb3 testsuite is disabled by default. Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default. BTW: How is a "resource" enabled by an user, without touching sourcecode?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSNJktZlgi5GaxT1NAQI7YQP+PwnNpfnJCsd3u/bAgjFQfHaRXMYlS1PN dZPb8lkzMbyanNituTC9VLxI97BXsSPSM7VNnbyO3lBVSvJxvsDaRDmoUynno+VX rw7+dD/mqKdyPujBjLzqYhbvQAoUOxLNac44/pTjvqoGiDa5CeR0AunUDnqnVVJa 4by7SBBxYrs= =sllZ -----END PGP SIGNATURE-----
On Sep 18, 2008, at 10:24 AM, Jesus Cea wrote:
Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default.
Perhaps so. That certainly improves the chances of finding problems early.
BTW: How is a "resource" enabled by an user, without touching sourcecode?.
regrtest.py takes a "-u" (for "use") option; take a look at how the value passed to that gets interpreted. (Could use better documentation, if no one's improved it since I added the option umpteen gazillion years ago.) -Fred -- Fred Drake <fdrake at acm.org>
On Thu, Sep 18, 2008 at 7:24 AM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Just installing 2.6rc2, I see that bsddb3 testsuite is disabled by default.
Current testsuite is far more fast and stable that the old one (entire test: 17 seconds in my machine). I was wondering if it is time to enable bsddb3 testsuite by default.
Well, 'time' says the test takes 16.09 sec user and 16.09 sec system on my MacBook, but a total execution time of almost 8 *minutes*. That is too long to be on by default. -Brett
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brett Cannon wrote:
Well, 'time' says the test takes 16.09 sec user and 16.09 sec system on my MacBook, but a total execution time of almost 8 *minutes*. That is too long to be on by default.
Uhmmmm... That is very strange. Under Solaris 10: """ [jcea@tesalia trunk]$ time python2.6 test.py -bv Found Berkeley DB 4.7 installation. include files in /usr/local/BerkeleyDB.4.7/include library files in /usr/local/BerkeleyDB.4.7/lib library name is libdb-4.7 running build running build_py running build_ext Running tests from /export/home/pybsddb/trunk/build - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berkeley DB 4.7.25: (May 15, 2008) bsddb.db.version(): (4, 7, 25) bsddb.db.__version__: 4.7.3pre9 bsddb.db.cvsid: $Id: _bsddb.c 620 2008-09-18 14:59:59Z jcea $ py module: /export/home/pybsddb/trunk/build/lib.solaris-2.10-i86pc-2.6/bsddb3/__init__.pyc extension module: /export/home/pybsddb/trunk/build/lib.solaris-2.10-i86pc-2.6/bsddb3/_pybsddb.so python version: 2.6rc2 (r26rc2:66504, Sep 18 2008, 15:51:56) [GCC 4.2.3] My pid: 17223 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ................................................................................................................................................................................................................................................................................................................................. - ---------------------------------------------------------------------- Ran 321 tests in 13.510s OK real 0m13.786s user 0m8.544s sys 0m1.636s """ A lot of the disk traffic generated by the testsuite is "syncronous". By default, under unix, the testsuite should be stored in "/tmp", that is usually a ramdisk or something similar. That is the case under Solaris 10. I don't know about MacOS. I'm executing the testsuite under linux, with a /tmp backed by a proper persistent FS (ReiserFS3). This machine is fairly busy, so the testsuite actual time should be better: """ jcea@castor:~/mnt/particion_1/python/pybsddb/trunk> time python test.py -bv Found Berkeley DB 4.3 installation. include files in /usr/include/db4 library files in /usr/lib library name is libdb-4.3 running build running build_py running build_ext Running tests from /home/jcea/mnt/particion_1/python/pybsddb/trunk/build - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.3.27: (September 9, 2005) bsddb.db.version(): (4, 3, 27) bsddb.db.__version__: 4.7.3pre9 bsddb.db.cvsid: $Id: _bsddb.c 620 2008-09-18 14:59:59Z jcea $ py module: /home/jcea/mnt/particion_1/python/pybsddb/trunk/build/lib.linux-i686-2.5/bsddb3/__init__.pyc extension module: /home/jcea/mnt/particion_1/python/pybsddb/trunk/build/lib.linux-i686-2.5/bsddb3/_pybsddb.so python version: 2.5.2 (r252:60911, Mar 13 2008, 12:51:08) [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] My pid: 19105 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ........................................................................................................................................................................................................................................................................................................................ - ---------------------------------------------------------------------- Ran 312 tests in 37.984s OK real 0m38.718s user 0m17.905s sys 0m3.252s """ - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSNRvtplgi5GaxT1NAQKf6QP+P1pYzY02dlgJCKoLLlSjlFwOKa+uWrjK pqbJJFKIf8RTbMWGIutYPr03pdI1T0Y3JadVfHDC/lAc/59BcbOtMhKYFlAFPlik ZEC9oW02zzve0+thwpmxMPeKA6CeLboYW+cGkoUhtGayffQObrrTh0Zi47BcTUL6 e46liag7/ZA= =TCJf -----END PGP SIGNATURE-----
On Fri, Sep 19, 2008 at 8:36 PM, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brett Cannon wrote:
Well, 'time' says the test takes 16.09 sec user and 16.09 sec system on my MacBook, but a total execution time of almost 8 *minutes*. That is too long to be on by default.
Uhmmmm... That is very strange.
Well, it has always been that way for me, so I always assumed test_bsddb3 was just a *really* long test.
A lot of the disk traffic generated by the testsuite is "syncronous". By default, under unix, the testsuite should be stored in "/tmp", that is usually a ramdisk or something similar. That is the case under Solaris 10.
I don't know about MacOS.
Don't think it is: drwxrwxrwt 11 root wheel 374B 19 Sep 20:44 tmp/
I'm executing the testsuite under linux, with a /tmp backed by a proper persistent FS (ReiserFS3). This machine is fairly busy, so the testsuite actual time should be better:
But you could have a faster CPU, more RAM, Reiser could easily be faster than HFS+, etc. There is no way any of these comparisons are going to work. OS X might just plain suck at running test_bsddb3. Only thing I can think of is that Berkeley DB 4.7 is a ton faster than 4.6 or I am running something differently than you: time ./python.exe Lib/test/regrtest.py -uall test_bsddb3 ~/Dev/python/2.x/pristine test_bsddb3 Berkeley DB 4.6.21: (September 27, 2007) Test path prefix: /var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/z-test_bsddb3-527 test_bsddb3 still working, be patient... 1 test OK. [48048 refs] ./python.exe Lib/test/regrtest.py -uall test_bsddb3 15.81s user 15.54s system 6% cpu 8:41.56 total -Brett
Only thing I can think of is that Berkeley DB 4.7 is a ton faster than 4.6 or I am running something differently than you:
My suspicion is that there is a bug somewhere, probably in Berkeley DB. For example, it might acquire some lock with a timeout, hoping that normally, the lock gets released elsewhere quickly. On OSX, for whatever reason, that assumption might be false, so the timeout eventually occurs, along with retries and whatnot. Of course, that's just a theory - one would have to debug the test suite to find out what's really going on. Regards, Martin
Brett> Well, it has always been that way for me, so I always assumed Brett> test_bsddb3 was just a *really* long test. Slow for me, but not nearly as bad as for you: % time ./python.exe ../Lib/bsddb/test/test_all.py -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006) bsddb.db.version(): (4, 4, 20) bsddb.db.__version__: 4.7.3pre5 bsddb.db.cvsid: $Id: _bsddb.c 66182 2008-09-03 17:50:32Z jesus.cea $ py module: /Users/skip/src/python/trunk/Lib/bsddb/__init__.pyc extension module: /Users/skip/src/python/trunk/regular/build/lib.macosx-10.3-i386-2.6/_bsddb.so python version: 2.6rc2+ (trunk:66519M, Sep 20 2008, 08:36:03) [GCC 4.0.1 (Apple Inc. build 5465)] My pid: 82520 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ............................................................. .... ---------------------------------------------------------------------- Ran 294 tests in 156.791s OK real 2m37.188s user 0m9.907s sys 0m6.196s One thing I noticed was that you and I are both using BerkDB 4.4.20 while Jesus is running 4.7.25. I can't get to 4.7.x with MacPorts, but I can get to 4.6.21. I installed that, rebuild bsddb with it and reran the tests: % time ./python.exe ../Lib/bsddb/test/test_all.py -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berkeley DB 4.6.21: (September 27, 2007) bsddb.db.version(): (4, 6, 21) bsddb.db.__version__: 4.7.3pre5 bsddb.db.cvsid: $Id: _bsddb.c 66182 2008-09-03 17:50:32Z jesus.cea $ py module: /Users/skip/src/python/trunk/Lib/bsddb/__init__.pyc extension module: /Users/skip/src/python/trunk/regular/build/lib.macosx-10.3-i386-2.6/_bsddb.so python version: 2.6rc2+ (trunk:66519M, Sep 20 2008, 08:36:03) [GCC 4.0.1 (Apple Inc. build 5465)] My pid: 21203 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ............................................................................................................................................................................................................................................................................................................ ---------------------------------------------------------------------- Ran 300 tests in 557.679s OK real 9m18.093s user 0m10.499s sys 0m16.709s Hmmm... Those extra six tests are expensive! I noticed there was a fair chunk of time where the CPU meter showed the CPU essentially idle and the dots were not moving. I trust it was waiting for the rather modest disk on my laptop. Next stop, in-memory disk (all commands as root): hdid -nomount ram://1024 newfs /dev/rdisk1 mkdir /tmp/mem mount /dev/disk1 /tmp/mem chmod 1777 /tmp/mem and rerun the tests with TMPDIR pointing at /tmp/mem. Whoops, it looks like test_support creates temp files in the current directory, ignoring TMPDIR or tempfile.gettempdir(). (Why is that???) So, cd to /tmp/mem first. Whoops! Again, the bsddb tests force the test database into /tmp. Fix test_all.py to use TMPDIR if set. Damn! 1gb isn't enough. I tried boosting it to 2gb. Still no go. Jesus, how big is your ramdisk? Here's a couple line patch for bsddb/test/test_all.py that uses TMPDIR if it's set. Index: Lib/bsddb/test/test_all.py =================================================================== --- Lib/bsddb/test/test_all.py (revision 66520) +++ Lib/bsddb/test/test_all.py (working copy) @@ -443,6 +443,9 @@ def set_test_path_prefix(path) : get_new_path.prefix=path +if "TMPDIR" in os.environ: + set_test_path_prefix(os.path.join(os.environ["TMPDIR"], "z-Berkeley_DB")) + def remove_test_path_directory() : test_support.rmtree(get_new_path.prefix) Skip
real 0m13.786s
test_bsddb3 takes about 30s real time on my system (Linux, with Berkeley DB 4.6.21). I don't think the default (of requiring the bsddb resource) can change for 2.6; we already have released rc2, so there won't be any further release candidates. For 2.7, I would still be hesitant to run this test by default - 30s is too long, IMO. It is unlikely that regular changes to Python break any of these tests, and if they do, the buildbots will tell. Anybody changing the bsddb library itself will know to run the full test suite. Regards, Martin
participants (5)
-
"Martin v. Löwis" -
Brett Cannon -
Fred Drake -
Jesus Cea -
skip＠pobox.com