Hi Zoe, great work on this new run-tests! :D
I was testing it and noticed a problem when running using the following command: $ ~/dev/php5_4/sapi/cli/php run-tests.php -z 8 -p ~/dev/php5_4/sapi/cli/php ~/dev/php5_4/ It shows the PHP messages: [...] Fatal error: Call to undefined function gzencode() in /home/felipe/dev/phpruntests/src/testcase/sections/configurationsections/rtGzipPostSection.php on line 23 [...] Notice: Undefined offset: 0 in /home/felipe/dev/phpruntests/src/testcase/rtTestDifference.php on line 91 Fatal error: Allowed memory size of 134217728 bytes exhausted at /home/felipe/dev/php5_4/Zend/zend_hash.c:330 (tried to allocate 81 bytes) in /home/felipe/dev/phpruntests/src/testcase/rtPhpTestFile.php on line 108 /home/felipe/dev/php5_4/Zend/zend_hash.c(551) : ht=0x7f96e6356a50 is inconsistent [...] Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/var_unserializer.re:290 (tried to allocate 32 bytes) in /home/felipe/dev/phpruntests/src/taskScheduler/rtTaskSchedulerFile.php on line 183 2012/5/17 zoe slattery <aparac...@gmail.com>: > Hi > > Over the past couple of weeks I have updated the parallel run-tests (fixed a > couple of minor bugs in the PHP code and the build.xml), it's now almost at > the point where I could go ahead and implement the last pieces. Here is a > summary and a few questions: > > 1. In rebasing the code the the dev't stream I found a number of tests with > non-standard sections. My code checks test case structure and objects to > anything non-standard, the current run-tests.php mainly ignores this kind of > thing. I fixed up about 15 of these tests (see #62022) already - I'll fix > the rest if there are no objections - I will open another bug report first. > > 2. If there is agreement to use this code it would make sense to replace > the existing run-tests code with it, or rather, it would make no sense to > try and maintain both versions. The new code is OO PHP, it's in > http://git.php.net/repository/phpruntests.git, is there any problem with it > staying there long term and maybe copying a run-tests.phar into the PHP > source directory? I have no idea what the right answer is, suggestions > welcome. > > 3. I ran a couple of small tests on my dual core Mac yesterday. For a > standard set of tests, the parallel code ran in 207 seconds, sequential in > 293 seconds and the standard run-tests.php took 298 seconds. This is an > improvement but I suspect we could still do better by looking at the > scheduling algorithm. > At the moment it's very simple, we just assemble a list of directories with > tests in and hand them out to processors till everything is done. Being able > to handle tests that must be run in sequence (mysql, mysqli) will mean > making some changes to this. So, perhaps we give an explicit list to p1 and > let the scheduler distribute the rest of the tests? Or maybe we should have > a 'process map' for all tests for extensions that are build by default? > Again, suggestions welcome. > > 4. REDIRECTTEST still needs to be implemented, I understand how it works and > this isn't (afaict) a major issue. > > 5. Testing. I'm able to do basic testing on Mac OSX and Linux. I really > need access to an 8 way Linux system, or someone who has access and would be > interested in looking at performance? Any volunteers? This is probably the > most interesting part of the project :-) > > 6. Windows. I'm not in a position to do anything much with Windows except > some very basic checks to make sure that the sequential version runs. The > parallel code won't work because we used pcntl(), however I know that Stefan > and George were keen to design the code so that a Windows solution could be > implemented if anyone thought of one. If anyone wants to pick up this aspect > I'd be happy to get them started. > > Zoe > > -- > PHP Quality Assurance Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
