Re: [Zope-dev] Test runner: layers, subprocesses, and tear down
Hello Benji, +1 for keeping the default as no subprocess and keeping the teardown. The others already said the reasons. -- Best regards, Adam GROSZERmailto:[EMAIL PROTECTED] -- Quote of the day: It is a great mistake to suppose that God is only, or even chiefly, concerned with religion. - William Temple, Archbishop of Canterbury ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: zc.testbrowser.real support for mozlab 0.1.9
On 2008-07-04 01:19:47 +0200, Graham Stratton [EMAIL PROTECTED] said:
I've checked in a branch with changes to the testbrowser.real code to
make it work with mozlab 0.1.9 (and firefox 3).
Hi Sebastian,
This is great. I spent all day yesterday trying to make this happen
and didn't get anywhere. Sometimes I wake up with a better idea as to
how to solve things, but I don't often wake up to find all the work's
been done!
I tried running the tests with Python 2.4. About half the time they
pass fine, and the other half fail something like this:
File doctest README.txt[40], line 1, in ?
browser.open('navigate.html')
File /Users/graham/development/patched_zc.testbrowser/src/zc/
testbrowser/real.py, line 201, in open
self.wait()
File /Users/graham/development/patched_zc.testbrowser/src/zc/
testbrowser/real.py, line 193, in wait
assert self.execute('tb_page_loaded;') == 'false'
AssertionError
though for varying pages with browser.open(). I don't understand what
could be causing it; why would that value be changed in between those
two lines? I guess the time.sleep() on line 191 implies that there's
something we might want to wait for. I increased it by 10x and only
got 1 failure out of 10, so I guess that helps.
I had this error, too and checked in a maybe-fix in r87964. Have you
tried with this revision or the one before? If it's thisone I'll add
another loop there.
--
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Itemtraverser and Unauthorized vs Views
Am 04.07.2008 um 07:37 schrieb Christian Theune:
On Fri, 2008-07-04 at 02:10 +0300, Marius Gedminas wrote:
On Tue, Jun 24, 2008 at 01:39:28PM +0200, Christian Theune wrote:
[...]
I can explicitly make the URL use '@@viewname' and bypass the
item traverser,
but I don't like the @@s in the URL. I wonder whether adding
Unauthorized to
the KeyError would be reasonable.
I think not. At least it should not convert Unauthorized into
NotFound.
If I can access a location (say, http://localhost/container/item)
when
I'm logged in, then if I try that as an anonymous user, I should
get an
authentication dialog rather than a 404 Not Found page.
Actually, in my case its, when logged in I can use:
http://localhost/container/view
When not logged in, I get an Unauthorized, although when accessing
http://localhost/container/@@view
I can go ahead as anonymous.
IMHO the code merging the namespaces should be more careful about
that.
IMHO the ItemTraverser should not lookup the view by itself, but
delegate to the 'view' traverser, somethind like:
def publishTraverse(self, request, name):
See zope.publisher.interfaces.IPublishTraverse
try:
return self.context[name]
except KeyError:
try:
return namespaceLookup('view', name, self.context,
request)
except TraversalError:
pass
raise NotFound(self.context, name, request)
Regards
Markus Kemmerling
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Thu Jul 3 11:00:00 2008 UTC to Fri Jul 4 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Jul 3 20:53:07 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009800.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 3 20:54:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009801.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 3 20:56:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009802.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 3 20:57:38 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009803.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Jul 3 20:59:08 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009804.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.testbrowser.real support for mozlab 0.1.9
While using the zc.testbrowser.real testbrowser we encountered a 'bug' in browser.contents. The doctype and html-tags are swallowed. I submitted a bug fix in #87999 on my branch. Regards, Sebastian -- Sebastian Wehrmann · [EMAIL PROTECTED] gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 12 · fax +49 345 1229889 1 Zope and Plone consulting and development smime.p7s Description: S/MIME Cryptographic Signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Thu, Jul 3, 2008 at 5:22 PM, Benji York [EMAIL PROTECTED] wrote: I'm working on making the zope.testing test runner run tests in parallelized subprocesses. The option will likely be spelled -j N, where N is the maximum number of processes. The branch (svn+ssh://svn.zope.org/repos/main/zope.testing/branches/benji-parallelize-subprocesses) is feature complete. I basically did a very simple transformation that resulted in the runner spawning subprocesses in threads, several at a time, instead of spawning them serially. The patch is less than 250 lines. Any critiques of the changes would be appreciated. No changes to the tear-down mechanism were made. All existing tests pass without modification. There aren't yet any tests for the new functionality. It may be tricky to test, so I have to think about that bit. I found that to eliminate nearly all CPU idle time, I had to use -j4 on my two core laptop. For a particular test corpus on a 4 core machine -j1 (the default) takes about 7 minutes -j6 takes about 2 minutes 20 seconds. If you use zc.buildout, then you can try the branch by checking it out, adding a develop entry into your buildout config referencing it, and updating any version spec for zope.testing to 3.6dev. I'd really like third-party confirmation of the total test time reductions I've seen. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TALES iterator odd/even reversal
--On 4. Juli 2008 02:05:30 +0300 Marius Gedminas [EMAIL PROTECTED] wrote: Recently I migrated a large-ish app built on Zope 3.2 to Zope 3.4. (About time I hear someone mumbling in the audience.) One strange difference was that TALES iterators swapped the meaning of odd and even, i.e. p tal:repeat=item python: [1, 2, 3, 4] span tal:condition=repeat/var/oddoddspan span tal:condition=repeat/var/evenevenspan /p produces different results on Zope 3.4 than it did on 3.2. First, your example does not work (must be repeat/item instead of repeat/var). Does anyone know why this is? Is this a bug? Should it be fixed? Where exactly is the bug? The output is even-odd-even-odd. The even/odd methods apply to the current iteration number afaik - but not to the variable within the current iteration itself. Or? Andreas pgpRMGppHEz20.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Test runner: layers, subprocesses, and tear down
Hi. Benji York wrote: If you use zc.buildout, then you can try the branch by checking it out, adding a develop entry into your buildout config referencing it, and updating any version spec for zope.testing to 3.6dev. I'd really like third-party confirmation of the total test time reductions I've seen. As this sounds very cool, I couldn't help but try it. I do get an error, though: Ran 80 tests with 2 failures and 0 errors in 37.463 seconds. Exception in thread Thread-1: Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 442, in __bootstrap self.run() File /opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/threading.py, line 422, in run self.__target(*self.__args, **self.__kwargs) File /opt/tmp/zope.testing/src/zope/testing/testrunner/runner.py, line 419, in spawn_layer_in_subprocess raise SubprocessError( SubprocessError: No subprocess summary found: Error: option --resume-layer not recognized This is inside a test collection in the Plone land, so there might be something on the various other layers involved here, that causes this. But maybe you have an idea what this is about? Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Deprecation warnings from 2.11.0
Sidnei da Silva wrote: On 6/25/08, Chris Withers [EMAIL PROTECTED] wrote: Cool. Are the deprecation warning common to Zope 2.11 across all platforms? I don't see a reason why not, specially if coming from that module. Did we as a community really release a stable version that emits deprecation warnings?! :-( Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3 on Python 2.5, Zope 3 releases
Martijn Faassen wrote: Hi there, I'm curious about the plans of Zope 3 on Python 2.5. Me too, and I have been for ages, but I've gotten nowhere :-( * Are people using Zope 3 with Python 2.5 already? What are your experiences? Apparently, it's all good to go, even RestrictedPython. The thing stopping me is that no-one seems willing and able (in that combination, I'm willing but don't have the right c-compiler) to build Windows binaries and get them up on PyPI. I'll ask again: what can I do to help with this? I particularly care about: zope.security zope.component zope.interface RestrictedPython ...and any dependencies. * Are there plans for a release after Zope 3.4? I'm just assuming that Zope 3.4.0c1 is actually the only release that Zope 3.4 is going to see. Any plans or interest in a Zope 3.5? I don't know what these mean anymore. With smaller eggs, surely it's just a case of getting compatible versions of the smaller libraries. And surely each egg's setup.py will make sure this happens? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test runner: layers, subprocesses, and tear down
Hi Benji, I've read the whole thread to date but thought I'd reply here... Benji York wrote: I'm working on making the zope.testing test runner run tests in parallelized subprocesses. The option will likely be spelled -j N, where N is the maximum number of processes. Cool :-) But please defauult to 1 for backwards compatability... I'd like to 1) remove the layer tear-down mechanism entirely, and 2) make (almost) all layers run in a subprocess. -lots to both of these I'm afraid. I've used tear-downs extensively for everything from shutting database connections to aborting transactions to dumping DemoStorages. I'm sure I'm not the only one.. As for all layers in a sub-process, I worry that this would break existing tests in some kind of horrible nasty way... I want to do #1 because it would simplify the test runner code and no one seems to be using the functionality anyway. It also appears from reading the code that any tests run in a subprocess (and most are) will never exercise the tear-down mechanism anyway. So I guess we're not currently running tests in a sub-process? My take on the pre-refactor testrunner was that a sub-process was only used when the testrunner was testing itself? #2 will add some process start-up overhead, but it'll only be one more process than is already started (and any reasonably-sized test corpus already starts several processes for each test run). The one exception is for running with -D or with a pdb.set_trace() embedded in the code under test. For that case we need a switch to say don't start any subprocesses at all, I suspect that will be spelled -j0. Right, I use this a lot. I guess -j0 should be the default for backwards compatability? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] TALES iterator odd/even reversal
On Fri, Jul 04, 2008 at 06:05:05PM +0200, Andreas Jung wrote: --On 4. Juli 2008 02:05:30 +0300 Marius Gedminas [EMAIL PROTECTED] wrote: Recently I migrated a large-ish app built on Zope 3.2 to Zope 3.4. (About time I hear someone mumbling in the audience.) One strange difference was that TALES iterators swapped the meaning of odd and even, i.e. p tal:repeat=item python: [1, 2, 3, 4] span tal:condition=repeat/var/oddoddspan span tal:condition=repeat/var/evenevenspan /p produces different results on Zope 3.4 than it did on 3.2. First, your example does not work (must be repeat/item instead of repeat/var). Right, sorry about that. Does anyone know why this is? Is this a bug? Should it be fixed? Where exactly is the bug? Zope 3.2 produces odd even odd even Zope 3.4 produces even odd even odd i.e. the meanings of odd and even have switched places. As a more concrete example, when renderin a table, the first row used to get the odd CSS class, but now is getting the even one. The output is even-odd-even-odd. The even/odd methods apply to the current iteration number afaik - but not to the variable within the current iteration itself. Or? Right. I'm now regretting my unfortunate example that used numbers as the items to be iterated over. Marius Gedminas -- Read what I mean, not what I write. signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Fri, Jul 04, 2008 at 11:50:34AM -0400, Benji York wrote: On Thu, Jul 3, 2008 at 5:22 PM, Benji York [EMAIL PROTECTED] wrote: I'm working on making the zope.testing test runner run tests in parallelized subprocesses. The option will likely be spelled -j N, where N is the maximum number of processes. The branch (svn+ssh://svn.zope.org/repos/main/zope.testing/branches/benji-parallelize-subprocesses) is feature complete. I basically did a very simple transformation that resulted in the runner spawning subprocesses in threads, several at a time, instead of spawning them serially. The patch is less than 250 lines. Any critiques of the changes would be appreciated. I'll try to take a look. I found that to eliminate nearly all CPU idle time, I had to use -j4 on my two core laptop. For a particular test corpus on a 4 core machine -j1 (the default) takes about 7 minutes -j6 takes about 2 minutes 20 seconds. I tried this in a Zope 3.4 checkout I had handy on a Core 2 Duo machine (1.8 GHz, running 64-bit Ubuntu Hardy). One test module could not be loaded, which explains the slightly lower number of tests reported: Test-module import failures: Module: zope.app.twisted.ftp.tests.test_zopetrial Traceback (most recent call last): File /home/mg/src/ivija-zope-3.4/Zope3.4/src/zope/app/twisted/ftp/tests/test_zopetrial.py, line 37, in ? orig_configure_logging = zope.testing.testrunner.configure_logging AttributeError: 'module' object has no attribute 'configure_logging' Here are the results: time# tests realusersystem reported old test runner 3m16.033s 2m44.670s 0m2.832s6895 zope.testing trunk 2m27.816s 1m58.971s 0m2.196s6890 new test runner -j0 2m37.322s 2m5.808s0m2.944s6890 new test runner -j1 2m32.249s 1m58.847s 0m2.652s6890 new test runner -j2 2m22.287s 3m51.214s 0m13.457s 584 new test runner -j3 2m20.560s 3m46.990s 0m12.613s 584 new test runner -j4 2m30.026s 3m43.198s 0m13.241s 584 At the end of the experiment I discovered that I have CPU frequency scaling enabled. It only scales down to 1.6 GHz and quickly jumps back up to 1.87 GHz. I find the speedup by switching to a modern test runner somewhat unexpected. Can those 5 missing tests really account for 45 seconds? Zope 3 appears to be composed of a multitude of small tests. If my numbers are correct, the advantage of using both CPU cores is almost completely negated by the extra bookkeeping that the test runner has to do. Visual ogling of my CPU usage applet shows that -j0/1 use only one CPU, while -j2 and above use only one CPU for the first test layer (zope.app.apidoc.testing.APIDocLayer) and then use both CPUs for the rest. Bug? The total number of tests is misreported when you have -jN with N 1. Test-module import failures is printed several times. test -j4 printed that message 37 times! test -j1 only did it once. -j2 and -j3 also did that a bit often (once per layer?) As far as I can understand, the granularity of the test distribution to CPUs is a test layer? If so, that's rather unfortunate for my application, which has only two layers (unit and functional). Especially given the quirk that the first test layer is run on one CPU while the other idles. Marius Gedminas P.S. Zope 3 is such a sweet little thing! All the tests finish in 3 minutes! Heaven. -- The planning fallacy is that people think they can plan, ha ha. -- Eliezer Yudkowsky, http://www.overcomingbias.com/2007/09/planning-fallac.html signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Fri, Jul 4, 2008 at 4:49 PM, Marius Gedminas [EMAIL PROTECTED] wrote: I tried this in a Zope 3.4 checkout I had handy on a Core 2 Duo machine (1.8 GHz, running 64-bit Ubuntu Hardy). One test module could not be loaded, which explains the slightly lower number of tests reported: Here are the results: time# tests realusersystem reported old test runner 3m16.033s 2m44.670s 0m2.832s6895 zope.testing trunk 2m27.816s 1m58.971s 0m2.196s6890 new test runner -j0 2m37.322s 2m5.808s0m2.944s6890 new test runner -j1 2m32.249s 1m58.847s 0m2.652s6890 new test runner -j2 2m22.287s 3m51.214s 0m13.457s 584 new test runner -j3 2m20.560s 3m46.990s 0m12.613s 584 new test runner -j4 2m30.026s 3m43.198s 0m13.241s 584 I'm really curious why you didn't see more improvement. At the end of the experiment I discovered that I have CPU frequency scaling enabled. It only scales down to 1.6 GHz and quickly jumps back up to 1.87 GHz. I find the speedup by switching to a modern test runner somewhat unexpected. Can those 5 missing tests really account for 45 seconds? Zope 3 appears to be composed of a multitude of small tests. If my numbers are correct, the advantage of using both CPU cores is almost completely negated by the extra bookkeeping that the test runner has to do. There's no appreciable bookkeeping for the parallelization, so I don't know where the CPU time is going. Visual ogling of my CPU usage applet shows that -j0/1 use only one CPU, while -j2 and above use only one CPU for the first test layer (zope.app.apidoc.testing.APIDocLayer) and then use both CPUs for the rest. Bug? Long story short: it made the changes to the code much less invasive to do that way. The total number of tests is misreported when you have -jN with N 1. I haven't seen that symptom, but I'll try to reproduce it by running the 3.4 tests. Test-module import failures is printed several times. test -j4 printed that message 37 times! test -j1 only did it once. -j2 and -j3 also did that a bit often (once per layer?) Interesting. I'll investigate. As far as I can understand, the granularity of the test distribution to CPUs is a test layer? Right. If so, that's rather unfortunate for my application, which has only two layers (unit and functional). Especially given the quirk that the first test layer is run on one CPU while the other idles. If the need is great enough, you can always introduce an arbitrary number of layers. Also, once this code is working properly, I (or someone else) might look into changing the granularity to the level of individual tests. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Fri, Jul 04, 2008 at 05:44:12PM -0400, Benji York wrote: On Fri, Jul 4, 2008 at 4:49 PM, Marius Gedminas [EMAIL PROTECTED] wrote: I tried this in a Zope 3.4 checkout I had handy on a Core 2 Duo machine (1.8 GHz, running 64-bit Ubuntu Hardy). One test module could not be loaded, which explains the slightly lower number of tests reported: Here are the results: time# tests realusersystem reported old test runner 3m16.033s 2m44.670s 0m2.832s6895 zope.testing trunk 2m27.816s 1m58.971s 0m2.196s6890 new test runner -j0 2m37.322s 2m5.808s0m2.944s6890 new test runner -j1 2m32.249s 1m58.847s 0m2.652s6890 new test runner -j2 2m22.287s 3m51.214s 0m13.457s 584 new test runner -j3 2m20.560s 3m46.990s 0m12.613s 584 new test runner -j4 2m30.026s 3m43.198s 0m13.241s 584 I'm really curious why you didn't see more improvement. I wish one of the system-wide profilers (oprofile, sysprof) had support for extracting Python tracebacks out of C-level stack frames... Zope 3 appears to be composed of a multitude of small tests. If my numbers are correct, the advantage of using both CPU cores is almost completely negated by the extra bookkeeping that the test runner has to do. There's no appreciable bookkeeping for the parallelization, so I don't know where the CPU time is going. Every layer is spawned in a separate subprocess, right? That means 36 new Python processes with the associated startup cost, plus the module import cost, plus some test result marshalling through plain-text Unix pipes. Two seconds of startup cost per subprocess would nicely account for the one extra minute of user time if there are over 30 subprocesses. My crude measurements (time ./test.py --list-tests /dev/null) indicate the time needed to import everything is closer to 4 seconds, but that's importing everything -- importing just the things needed for a single layer may reduce that to two seconds on average. Test-module import failures is printed several times. test -j4 printed that message 37 times! test -j1 only did it once. -j2 and -j3 also did that a bit often (once per layer?) Interesting. I'll investigate. It corroborates my theory that each subprocess imports all the test modules. Marius Gedminas -- H.323 has much in common with other ITU-T standards - it features a complex binary wire protocol, a nightmarish implementation, and a bulk that can be used to fell medium-to-large predatory animals. -- Anthony Baxter signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Fri, Jul 4, 2008 at 6:43 PM, Marius Gedminas [EMAIL PROTECTED] wrote: On Fri, Jul 04, 2008 at 05:44:12PM -0400, Benji York wrote: There's no appreciable bookkeeping for the parallelization, so I don't know where the CPU time is going. Every layer is spawned in a separate subprocess, right? That means 36 new Python processes with the associated startup cost, plus the module import cost, plus some test result marshalling through plain-text Unix pipes. Two seconds of startup cost per subprocess would nicely account for the one extra minute of user time if there are over 30 subprocesses. The number of subprocesses is the same as for the trunk, the only change is that they can be spawned in parallel. Wait! The Zope 3 test layers can all be torn down! Therefore there aren't *any* subprocesses spawned normally. Ok, that makes more sense. (time passes) OK, I did a check out of the Zope 3 trunk and was able to duplicate your results. (And wow, the trunk seems to be in bad shape -- lots of tests failing. I guess it's fallen into disrepair since being broken out into subprojects.) My crude measurements (time ./test.py --list-tests /dev/null) indicate the time needed to import everything is closer to 4 seconds, but that's importing everything -- importing just the things needed for a single layer may reduce that to two seconds on average. A possible enhancement would be to reuse subprocesses if they are asked to run layers that can be torn down. That way for a very tear-down friendly set of tests like Zope 3's, the minimum number of processes would be started. We could also use fork to eliminate some of the start-up cost, but that's not real attractive, being un-Windows-friendly. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Test runner: layers, subprocesses, and tear down
On Fri, Jul 4, 2008 at 4:49 PM, Marius Gedminas [EMAIL PROTECTED] wrote: Here are the results: time# tests realusersystem reported old test runner 3m16.033s 2m44.670s 0m2.832s6895 zope.testing trunk 2m27.816s 1m58.971s 0m2.196s6890 new test runner -j0 2m37.322s 2m5.808s0m2.944s6890 new test runner -j1 2m32.249s 1m58.847s 0m2.652s6890 new test runner -j2 2m22.287s 3m51.214s 0m13.457s 584 new test runner -j3 2m20.560s 3m46.990s 0m12.613s 584 new test runner -j4 2m30.026s 3m43.198s 0m13.241s 584 I figured out why the total test count went down so much for -j2: the branch inherited a bug from the trunk that skips the unit test layer if it is run in a subprocess. I'll take a crack at fixing that. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
