PHP Micro-Benchmark-Suite

22 years ago by Zeev Suraski — view source — reply

unread

I think you should use a slightly larger scale for bcsub() - the numbers
you're getting are too 'beautiful' (909090, 666666, 1000000, etc. :)

Zeev

At 11:09 26/06/2003, Sebastian Bergmann wrote:

I started working on a PHP Micro-Benchmark-Suite [1] to track
changes in performance between PHP releases.

Currently it tests some aspects of Array and OOP operations.

Comments / Improvements are welcome,
Sebastian

--
[1]
http://www.sebastian-bergmann.de/blog/archives/104_PHP_MicroBenchmarkSuite.html

--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
     http://www.professionelle-softwareentwicklung-mit-php5.de/

22 years ago by Sebastian Bergmann — view source — reply

unread

Zeev Suraski wrote:

I think you should use a slightly larger scale for bcsub()

I updated the script to

- have a configurable scale

- use a default scale of 12

--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/

     http://www.professionelle-softwareentwicklung-mit-php5.de/

22 years ago by Rob Richards — view source — reply

unread

Will there be an "official" supported version of libxml now that there are
many xml extensions using it?

One issue that came up with the old domxml extension was that occasionally
new versions of libxml would "fix" things which ended up changing behavior
of the extension. With more extensions it could be more difficult to
determine exactly what is a bug and what is due to code changes in libxml,
as well as that some extensions may be affected by the changes and some may
not.

Under win32 for instance, in order to use a stock libxml2.dll, it must be
version 2.5.x (not sure the exact start version) otherwise the symbols
simplexml need are unavailable and would need libxml compiled in statically.

Having at least one version defined as compatible would make it much easier
for testing and debugging across all the extensions while other libxml
versions could be run at your own risk.

Rob

22 years ago by Zeev Suraski — view source — reply

unread

FWIW, that's one of the key reasons I think we should default to use the
bundled libxml, and only use the system library if the user explicitly
requested that. I think we're going to bundle libxml in beta1 to see how
well this concept works.

Zeev

At 15:25 26/06/2003, Rob Richards wrote:

Will there be an "official" supported version of libxml now that there are
many xml extensions using it?

One issue that came up with the old domxml extension was that occasionally
new versions of libxml would "fix" things which ended up changing behavior
of the extension. With more extensions it could be more difficult to
determine exactly what is a bug and what is due to code changes in libxml,
as well as that some extensions may be affected by the changes and some may
not.

Under win32 for instance, in order to use a stock libxml2.dll, it must be
version 2.5.x (not sure the exact start version) otherwise the symbols
simplexml need are unavailable and would need libxml compiled in statically.

Having at least one version defined as compatible would make it much easier
for testing and debugging across all the extensions while other libxml
versions could be run at your own risk.

Rob

22 years ago by Adam Dickmeiss — view source — reply

unread

FWIW, that's one of the key reasons I think we should default to use the
bundled libxml, and only use the system library if the user explicitly
requested that. I think we're going to bundle libxml in beta1 to see how
well this concept works.
Bundling gives many problems. So if a Unix machine has libxml/libxslt
installed (most do) and if that version is supported by PHP the configure
should use that (and not a bundled version). If the PHP people
only allows a very strict set of libxml versions that's a sign
of a problem in ext/xml.* (not in libxml). libxml API doesn't change.

-- Adam

Zeev

At 15:25 26/06/2003, Rob Richards wrote:

Will there be an "official" supported version of libxml now that there are
many xml extensions using it?

One issue that came up with the old domxml extension was that occasionally
new versions of libxml would "fix" things which ended up changing behavior
of the extension. With more extensions it could be more difficult to
determine exactly what is a bug and what is due to code changes in libxml,
as well as that some extensions may be affected by the changes and some may
not.

Under win32 for instance, in order to use a stock libxml2.dll, it must be
version 2.5.x (not sure the exact start version) otherwise the symbols
simplexml need are unavailable and would need libxml compiled in
statically.

Having at least one version defined as compatible would make it much easier
for testing and debugging across all the extensions while other libxml
versions could be run at your own risk.

Rob

--

--

--
Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk
Index Data T: +45 33410100 Mob.: 212 212 66

22 years ago by Rob Richards — view source — reply

unread

From: Adam Dickmeiss

Bundling gives many problems. So if a Unix machine has libxml/libxslt
installed (most do) and if that version is supported by PHP the configure
should use that (and not a bundled version). If the PHP people
only allows a very strict set of libxml versions that's a sign
of a problem in ext/xml.* (not in libxml). libxml API doesn't change.

I am not suggesting that we restrict the versions of libxml that people can
use. The API calls may not change, but the logic within can and does.
Without being able to say that versions x,y,z are supported, what is
considered a PHP bug and what is considered a change from libxml (and how
can we tell).

We are going to be right back to bug reports where people say things are
broken when it is really that they are running newer/different versions of
libxml. Who decides which is right? Are all the extension maintainers
supposed to get togther agree to an upgrade and then start writing custom
xml code in order to support the older versions and not break BC? Do you
know how many times I have gone through different versions of libxml souce
code from bug reports when it ended up being changes within libxml.

It was a pain to deal with when there is a single extension using it, but
now there are currently 3 that depend on it, 1 that uses it but can use
expat, and another one on its way that will depend upon it. It could turn
into a nightmare.

All I am suggesting is that there is a version(s) - could be more than one -
that the extensions are based on and tested against. If people are running
something different and the behavior of the library has changed it is not a
bug in PHP, so they have the option to live with the changed behavior or run
with a supported version.

Rob