# PHP Micro-Benchmark-Suite - Thread: https://externals.io/message/2823 - Original archive: https://news-web.php.net/php.internals/2823 - Started by Zeev Suraski on 2003-06-26T10:33:36+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #2823 — Zeev Suraski — 2003-06-26T10:33:36+00:00 URL: https://externals.io/message/2823#2823 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/ --- ## #2824 — Sebastian Bergmann — 2003-06-26T10:56:25+00:00 URL: https://externals.io/message/2823#2824 · In reply to: #2823 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/ --- ## #2825 — Rob Richards — 2003-06-26T12:25:21+00:00 URL: https://externals.io/message/2823#2825 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 --- ## #2827 — Zeev Suraski — 2003-06-26T12:53:09+00:00 URL: https://externals.io/message/2823#2827 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 --- ## #2828 — Adam Dickmeiss — 2003-06-26T13:09:51+00:00 URL: https://externals.io/message/2823#2828 · In reply to: #2827 > 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: > > […] > > > -- > > -- Adam Dickmeiss mailto:adam@indexdata.dk http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66 --- ## #2832 — Rob Richards — 2003-06-26T13:46:40+00:00 URL: https://externals.io/message/2823#2832 · In reply to: #2828 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