Mmmm,
since this is -dev I'm just going to
#include usual extensive benchmark disclaimers
case in point, the php and perl version are not written same way aka same
logic and data structures. Rewriting the perl version with a while contruct
actually speeds it up (and re-inforces the fact that
- Original Message -
From: Sebastian Bergmann [EMAIL PROTECTED]
Newsgroups: php.dev
To: [EMAIL PROTECTED]
Sent: Monday, December 31, 2001 11:04 AM
Subject: Re: [PHP-DEV] Re: MOPS Benchmark
August Zajonc wrote:
My results are very close to Andrew Sitnikov's.
Guys,
please don't
In conjunction with this, increasing the findability of the PECL might be a
good idea.
At the least an explict search at php.net either in documentation or
whole site should result in at least one hit other than a changelog entry.
- AZ
- Original Message -
From: Jon Parise [EMAIL
That was me :)
Fantastic, especially the fact that someone had a copy of the old messages.
Might consider reflecting the archive either through the newsgroup interface
or marc.theaimsgroup.com...
Thanks a lot, been hoping for this for a while.
- August
- Original Message -
From: Andi
It should be noted that the shootout reflects rather poorly on PHP. Ranks
second to last on the overall scorecard, partly because it is missing some
tests. On the tests it does perform on a quick check shows it generally uses
significantly more CPU time to do various computations then many of the
Can someone run a few of these tests on a machine with --disable-debug.
I'd be curious to know how much of a difference that might make.
-AZ
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To
This is not really surprising, and the test is not really fair, the
PHP code is not written by an experienced php programmer, and thus,
would naturally be slower, on person benchmarks like this are simply
too dependent on the person writing the code.
-Sterling
Give me a
This is not really surprising, and the test is not really fair, the
PHP code is not written by an experienced php programmer, and thus,
would naturally be slower, on person benchmarks like this are simply
too dependent on the person writing the code.
-Sterling
Give me a
This is not really surprising, and the test is not really fair, the
PHP code is not written by an experienced php programmer, and thus,
would naturally be slower, on person benchmarks like this are simply
too dependent on the person writing the code.
-Sterling
Give me a
Sure,
These are not my tests but Doug's. He compiled default so --debug
and --inline-optimization not kicking in. Startup cost also counted, but he
tried to run long enough to amortize that.
n was 16.
perl code was something like this.
#!/usr/local/bin/perl
# $Id: nestedloop.perl,v 1.2
performance wise. My sense
is that the focus is more feature oriented.
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: August Zajonc [EMAIL PROTECTED]
Cc: Sterling Hughes [EMAIL PROTECTED]; Markus Fischer
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, December 29, 2001 9:27 AM
- Original Message -
From: Sterling Hughes [EMAIL PROTECTED]
The point, if you'd really like to know is that PHP is *not*
optimized to do matrix operations (which is one of the examples), or
infinitely recursive loops (I'm not even addressing the code at this
point)
Mmmm :)
I suggest you check out php-gtk. People are writing mail clients in PHP (and
they are actually *suprisingly* good).
The strengths of PHP (and time spent learning it) in one area carry over to
others. We'll have to be wondering about misuse when a CS student writes an
operating system in
Mike,
I would suggest you look at the totally bogus mindcraft benchmarks of
linux/apache. Those were orders of magnitude more bogus than anything here,
yet ended up being useful.
Further, many posters seem to confuse a discussion of PHP's performance with
a dicusion of its quality as a language
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
If you use caching software, chances are PHP will be faster than Perl even
without the optimizer.
Interestingly, Perl is getting bytecode caching soon, RFC 301 I think.
Probably about time.
And it does that without any hassle
- Original Message -
From: Sterling Hughes [EMAIL PROTECTED]
Manuel,
(I get all the trolls confused, one name makes it easier)
These trolls happen to use PHP on a daily basis, and have for years.
Always good to see the name calling start early :)
Thanks! I wasn't aware
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
That RFC is from over a year ago, what makes you think it's going to
happen
soon..? It still remains to be seen if they do it in a nice, clean
transparent way, or the Perl way :) Anyway, the other problems plaguing
Perl
:)
- August
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: August Zajonc [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, December 29, 2001 3:51 PM
Subject: RE: [PHP-DEV] Re: Shootout
I have to say that taking a look at his site again - he does have
I've really run into a wall trying to get single charachters from stdin.
Something similar to the getchar macro or a real fgetc would be nice.
The current behavior is that more than a signle charachter can be typed and
fgetc only returns when it sees a \n.
I'd like it to return immediatly
:[EMAIL PROTECTED]]
Sent: Saturday, December 15, 2001 1:34 PM
To: August Zajonc; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Unbuffered fgetc needed for stdin
This usually depends on how you configured your tty. I think by
default it
is buffered by the OS until a newline so it's probably not PHP
Redirecting bugs to -qa is excellent. -dev is no fun to actually subscribe
to with the number of support requests alone coming in. I imagine folks have
gotten pretty good at ignoring em but... Let's do it.
Be nice to see the possibility of third party comments to bugs as well for
confirms,
How is this -dev?
How is it php?
This is crossposted.
-AZ
Hew Staff [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Hi,
I'm trying to pull a random row from my database and display the contents.
I know that the code:
SELECT * FROM TABLENAME WHERE RAND()
st...
I promised that anybody that I'll break the neck of anybody that complains
about not going with the GPL. Please inform me of any PHP conferences you
intend to attend, so I know where to find you :)
Zeev
At 20:28 08/11/2001, August Zajonc wrote:
Why not the GPL?
But excellent any w
Why not have an abstraction? It would seem this would allow scanners with
different licenses to co-exist, and more to the point there's an immediate
technical win here, with code already written.
Looking over the patch it appears that this wouldn't effect most people
unless they
scanner
the license seems very open?
AZ
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 5:10 PM
To: August Zajonc
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] [UPDATE] NGScan
At 23:57 9/7/2001, August Zajonc wrote:
Why not have an abstraction
I suspect this is likely a browser issue rather than a PHP issue.
Can you flesh out a bit what PHP is doing wrong and what needs to be done to
fix this "BUG"?
Alternatively, you could submit a question to php-general...
AZ
- Original Message -
From: [EMAIL PROTECTED]
Newsgroups:
What about leveraging an existing bug system? There is Alexandria over at
sourceforge which looks like it is still in development, and by enhancing it
projects at sourceforge may also benefit.
It sometimes seems that some of the best aspects of open source are not
taken advantage of.
A ton of
27 matches
Mail list logo
