Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries
Edit report at https://bugs.php.net/bug.php?id=53458&edit=1
ID: 53458
Comment by: don at smugmug dot com
Reported by: don at smugmug dot com
Summary:Non-linear performance degradation on certain
prepared SELECT queries
Status: Analyzed
Type: Bug
Package:PDO related
Operating System: CentOS 5.5
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Sorry for the script getting lost, been awhile. :) Here's a gist with it:
https://gist.github.com/onethumb/5198291
The thing that still leaves me wondering after your analysis is why doing a
prepared SELECT on 1K rows, ten times, results in a >10X faster return than a
single SELECT on 10K rows? Presumably, we'd have the same # of calls both ways?
I just validated against 5.4.10, too. Same problem.
Previous Comments:
[2013-03-19 16:34:04] m...@php.net
The test script is not accessible anymore, so I assume it is about
$stm->execute($a10kArray)
If that is the case, then the issue might be described as follows:
Each element in the array to stm->execute() is registered as a bound parameter,
for which the param_hook callback is called twice (normalize and alloc) and
once when everything is done (free).
So for a 10k array, this are 30k callbacks into the pdo driver.
When fetching a row, the param_hook callback is called twice for each param
(fetch_pre and fetch_post), i.e. 20k callbacks.
So for a 10k rowset add 200M calls.
In numbers: 200,030,000 indirect calls to the param_hook callback of the
underlying pdo driver.
Iterating over the 10k params twice for each of the 10k rows is nearly (twice
in a debug build) as expensive as calling the param_hook itself.
Add this two things up, and you easily wait a second for your result set.
[2010-12-03 04:27:43] w...@php.net
from a twitter conversation with Don, the heart of this issue is that the there
appears to be a difference in the performance of fetch() or fetchAll()
depending
on whether query() or prepare() + execute() were used.
Given that query() is really just prepare() + execute() under the covers, it is
difficult to explain this difference.
[2010-12-03 03:36:14] don at smugmug dot com
FYI, setting PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to true/false didn't have a
large impact. Still ~10X slower than any of the other methods either way.
(Buffered was slightly faster)
--------
[2010-12-02 23:39:10] don at smugmug dot com
Here's my PHP build configuration:
'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf' '--with-jpeg-
dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib' '--
enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc' '--with-
curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-
bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl'
'--with-mysqli=mysqlnd'
[2010-12-02 23:29:50] don at smugmug dot com
Description:
When retrieving results from prepared PDO statements against MySQL, we get
performance that diverges from expected by 10X or more on results as low as
1
rows. This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.
The attached script provides two PDO prepared approaches ('row-prepared',
default,
and 'all-prepared') as well as a variety of control methods that use
non-prepared
PDO queries, straight MySQL, and prepared queries using MySQLi. Only PDO with
prepared queries exhibits the problem.
If the query is broken up into chunks that return 1000 rows or less prior to
execution, then combined afterwards in PHP, performance is as expected.
Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz
Expected result:
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared should
return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).
Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared return
in
~6s instead of ~0.5s
--
Edit this bug report at https://bugs.php.net/bug.php?id=53458&edit=1
Bug #63976 [Com]: Parent class incorrectly using child constant in class property
Edit report at https://bugs.php.net/bug.php?id=63976&edit=1 ID: 63976 Comment by: don at smugmug dot com Reported by: don at smugmug dot com Summary:Parent class incorrectly using child constant in class property Status: Assigned Type: Bug Package:Class/Object related Operating System: Ubuntu 12.04 PHP Version:5.4.10 Assigned To:dmitry Block user comment: N Private report: N New Comment: I have validated that the patch solves our use case (and the test case in this bug). Thanks Mike! Previous Comments: [2013-03-14 09:01:59] m...@php.net @dmitry, can you have a look at the , please? The condition could actually be simplified to if (ce->type == ZEND_USER_CLASS) ... Thank you. [2013-02-14 17:30:36] m...@php.net The following patch has been added/updated: Patch Name: update_class_constants Revision: 1360863036 URL: https://bugs.php.net/patch-display.php?bug=63976&patch=update_class_constants&revision=1360863036 [2013-01-12 03:53:33] don at smugmug dot com 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. -------- [2013-01-12 03:51:21] don at smugmug dot com Description: Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: Consistent results for Baz->table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz->table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz->table == 'foo' in the examples). Actual result: -- brokenA.php: Bar Object ( [table] => bar ) Baz Object ( [table] => foo ) brokenB.php: Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) brokenC.php: Baz Object ( [table] => baz ) Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) -- Edit this bug report at https://bugs.php.net/bug.php?id=63976&edit=1
Bug #61411 [Com]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411&edit=1
ID: 61411
Comment by: don at smugmug dot com
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE &&
EMULATE_PREPARES == FALSE
Status: Re-Opened
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Assigned To:uw
Block user comment: N
Private report: N
New Comment:
FWIW, 5.3.3 segfaults like this, but 5.3.2 doesn't. I spot-checked a handful
of
other versions up to .21 and they all segfaulted as well.
Previous Comments:
[2013-01-18 01:07:03] don at smugmug dot com
I can reproduce this in 5.4.10 and 5.4.4, FWIW.
[2013-01-08 17:48:23] ras...@php.net
I can still reproduce this in PHP 5.4.12-dev built today.
[2013-01-08 12:18:49] johan...@php.net
Related To: Bug #53716
[2012-05-04 08:56:52] u...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/68917
[2012-05-02 09:14:42] u...@php.net
Andrey,
do you think we should mnd_p*alloc(.., .., stmt->persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt->result_bind) {
1625andrey 289028 stmt->result_bind = mnd_ecalloc(stmt->field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt->result_bind = mnd_erealloc(stmt->result_bind,
stmt->field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61411
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411&edit=1
Bug #61411 [Com]: PDO Segfaults with PERSISTENT == TRUE && EMULATE_PREPARES == FALSE
Edit report at https://bugs.php.net/bug.php?id=61411&edit=1
ID: 61411
Comment by: don at smugmug dot com
Reported by:julien at palard dot fr
Summary:PDO Segfaults with PERSISTENT == TRUE &&
EMULATE_PREPARES == FALSE
Status: Re-Opened
Type: Bug
Package:PDO related
Operating System: Linux 2.6.32-5-amd64
PHP Version:5.4.0
Assigned To:uw
Block user comment: N
Private report: N
New Comment:
I can reproduce this in 5.4.10 and 5.4.4, FWIW.
Previous Comments:
[2013-01-08 17:48:23] ras...@php.net
I can still reproduce this in PHP 5.4.12-dev built today.
[2013-01-08 12:18:49] johan...@php.net
Related To: Bug #53716
[2012-05-04 08:56:52] u...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
http://news.php.net/php.cvs/68917
[2012-05-02 09:14:42] u...@php.net
Andrey,
do you think we should mnd_p*alloc(.., .., stmt->persistent) here?
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/mysqlnd/mysqlnd_ps.c?annotate=321634
1624if (!stmt->result_bind) {
1625andrey 289028 stmt->result_bind = mnd_ecalloc(stmt->field_count,
sizeof(MYSQLND_RESULT_BIND));
1626andrey 258383 } else {
1627andrey 289028 stmt->result_bind = mnd_erealloc(stmt->result_bind,
stmt->field_count * sizeof(MYSQLND_RESULT_BIND));
1628andrey 258383 }
[2012-03-16 09:16:27] julien at palard dot fr
Description:
PDO Segfaults or hangs when a statement is executed with both ATTR_PERSISTENT
=>
TRUE and ATTR_EMULATE_PREPARES => FALSE
The exact bug is actually :
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
But from my tests yesterday I have seen a segfault and a double free, that I
can't reproduce today, only the invalid pointer.
Playing with PERSISTENT and EMULATE_PREPARE with the given test script give :
| ATTR_PERSISENT | ATTR_EMULATE_PREPARES | WORKS |
| FALSE | FALSE |YES |
| FALSE | TRUE |YES |
| TRUE | FALSE | free() invalid pointer |
| TRUE | TRUE |YES |
Configure command :
./configure' '--enable-fpm' '--prefix=/usr/local/php-5.4.0'
'--enable-mbstring'
'--enable-gd-native-ttf' '--enable-zip' '--with-mcrypt' '--with-openssl' '--
with-gd' '--with-jpeg-dir=/usr/lib' '--with-freetype-dir' '--with-curl' '--with-
pcre-regex' '--with-gettext' '--without-sqlite' '--without-sqlite3' '--with-pdo-
mysql=mysqlnd' '--disable-rpath' '--disable-debug' '--disable-fileinfo' '--
without-pdo-sqlite' '--disable-phar' '--disable-posix' '--disable-tokenizer' '--
disable-xmlreader' '--disable-xmlwriter' '--without-pear'
Same bug reproduced in php 5.3.8 and php 5.3.10
Test script:
---
TRUE,
PDO::ATTR_EMULATE_PREPARES => FALSE);
$pdo = new PDO('mysql:host=sql;dbname=??;charset=utf8',
'??', '??', $options);
$statement = $pdo->prepare("SELECT count(*) from a_table");
$statement->execute();
foreach ($statement as $line)
var_dump($line);
Expected result:
I expect PHP not to segfault
Actual result:
--
*** glibc detected *** /usr/local/php-5.4.0/bin/php: free(): invalid pointer:
0x7ff976ee84c8 ***
--
Edit this bug report at https://bugs.php.net/bug.php?id=61411&edit=1
Bug #63976 [Opn]: Parent class incorrectly using child constant in class property
Edit report at https://bugs.php.net/bug.php?id=63976&edit=1 ID: 63976 User updated by: don at smugmug dot com Reported by: don at smugmug dot com Summary:Parent class incorrectly using child constant in class property Status: Open Type: Bug Package:Class/Object related Operating System: Ubuntu 12.04 PHP Version:5.4.10 Block user comment: N Private report: N New Comment: 'Have a preference' should have said 'I have a preference'. Certainly not intending for PHP to add some new INI option or something to change how static:: and self:: behave. :) Also, have confirmed this on 5.4.4 and CentOS in addition to Ubuntu and 5.4.10, both with and without extensions like APC loaded. Previous Comments: ---- [2013-01-12 03:51:21] don at smugmug dot com Description: Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: Consistent results for Baz->table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz->table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz->table == 'foo' in the examples). Actual result: -- brokenA.php: Bar Object ( [table] => bar ) Baz Object ( [table] => foo ) brokenB.php: Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) brokenC.php: Baz Object ( [table] => baz ) Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) -- Edit this bug report at https://bugs.php.net/bug.php?id=63976&edit=1
[PHP-BUG] Bug #63976 [NEW]: Parent class incorrectly using child constant in class property
From: don at smugmug dot com Operating system: Ubuntu 12.04 PHP version: 5.4.10 Package: Class/Object related Bug Type: Bug Bug description:Parent class incorrectly using child constant in class property Description: Class properties that rely on potentially inherited class constants have unpredictable behavior. Since PHP doesn't support Child class properties referencing static values like static::CONST, the meaning of self::CONST is ambiguous. One of two things should happen: 1. It should use the value defined in the actual class in question (like self:: is used throughout the rest of PHP). 2. It should treat self:: in this case, since it's compile-time and not late static binding, like static:: and walk the inheritance tree, delivering the result for the Child class. Option #1 seems the most sane, but PHP often behaves like it intends #2 to work. But not always... In the provided examples, 'brokenA.php' behaves like #1, above, while 'brokenB.php' and 'brokenC.php' behave like #2. The only thing that's changed is the order in which the classes are require()'d. In a complex script, with autoloaders, class instantiation order isn't predictable, of course, resulting in unpredictable results. Test script: --- Example code: https://github.com/onethumb/php-parent-child-constant-bug Expected result: Consistent results for Baz->table. Either 'foo' or 'baz' 100% of the time, rather than mixed up depending on require() order. Have a preference for adding static::CONST to PHP and making self::CONST behave like self:: does in the rest of the language (resulting in Baz->table == 'baz' in the examples if we used static::CONST), but if that's not preferable for some reason, self::CONST should probably behave like self:: everywhere else (resulting in Baz->table == 'foo' in the examples). Actual result: -- brokenA.php: Bar Object ( [table] => bar ) Baz Object ( [table] => foo ) brokenB.php: Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) brokenC.php: Baz Object ( [table] => baz ) Bar Object ( [table] => bar ) Baz Object ( [table] => baz ) -- Edit bug report at https://bugs.php.net/bug.php?id=63976&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63976&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63976&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63976&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63976&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63976&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63976&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63976&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63976&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63976&r=support Expected behavior: https://bugs.php.net/fix.php?id=63976&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63976&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63976&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63976&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63976&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63976&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63976&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63976&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63976&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63976&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63976&r=mysqlcfg
Req #49366 [Com]: Make slash escaping optional in json_encode()
Edit report at https://bugs.php.net/bug.php?id=49366&edit=1 ID: 49366 Comment by: don at smugmug dot com Reported by: don at smugmug dot com Summary:Make slash escaping optional in json_encode() Status: Closed Type: Feature/Change Request Package:JSON related Operating System: CentOS 5.3 PHP Version:5.3.0 Assigned To:aharvey Block user comment: N Private report: N New Comment: I totally agree that this should just be the default, rather than some new option. Both ways are 100% JSON compliant, but one (the PHP chosen method) is far less common, has a significantly larger footprint on lots of common types of data, and is harder for humans to read. I see no benefit t Previous Comments: [2011-12-15 22:05:06] dtremblay dot fafard at gmail dot com Actually, I can't find any reason why is escaping slashes by default and create an option to remove this feature. Usually, when you want something added (e.g. Escaping Slashes), you use an option to recreate the feature wanted. So why is the option used to REMOVE a feature? Options exists to add features, not remove them?? Where am I wrong? [2010-09-16 15:53:38] ahar...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. I've implemented this on trunk via a json_encode() option called JSON_UNESCAPED_SLASHES. The default behaviour remains to escape slashes. [2010-09-16 15:53:29] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=303421 Log: Implemented FR #49366 (Make slash escaping optional in json_encode()). [2010-08-08 14:43:22] jd2 at dilltree dot com Totally agree. This is needed for anything such as a REST service that wants to return JSON with valid urls. [2009-10-21 21:14:40] jemptymethod at acm dot org I concur with the suggested course of action making the escaping of slashes controllable with a flag as I'm experiencing the same issue as the OP albeit on Debian (rather than CentOS) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=49366 -- Edit this bug report at https://bugs.php.net/bug.php?id=49366&edit=1
Bug #54723 [Opn]: getimagesize() incorrectly identifies files as ICO which aren't
Edit report at http://bugs.php.net/bug.php?id=54723&edit=1 ID: 54723 User updated by: don at smugmug dot com Reported by: don at smugmug dot com Summary:getimagesize() incorrectly identifies files as ICO which aren't Status: Open Type: Bug Package:GetImageSize related Operating System: CentOS 5.5 PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Grr. Instead of "are uploaded" that should read "are passed to getimagesize()". Sorry about that. Previous Comments: -------- [2011-05-12 19:12:45] don at smugmug dot com Description: When certain types of files are uploaded, including .MPGs, getimagesize() incorrectly identifies them as ICOs with a MIME type of 'image/vnd.microsoft.icon'. I suspect certain files probably have embedded icons in them, which is what PHP is detecting and reporting, but the actual file isn't an ICO. A ~500K sample file can be found here: http://www.smugmug.com/img/video/problem/php-getimagesize.mpg Expected result: I'd expect FALSE to return, since this isn't a picture and isn't a valid type PHP knows about. Actual result: -- It returns this array: array(0 => 45, 1 => 82, 2 => 17, 3 => 'width="45" height="82"', 'bits' = 65023, 'mime' = 'image/vnd.microsoft.icon'); -- Edit this bug report at http://bugs.php.net/bug.php?id=54723&edit=1
[PHP-BUG] Bug #54723 [NEW]: getimagesize() incorrectly identifies files as ICO which aren't
From: Operating system: CentOS 5.5 PHP version: 5.3.6 Package: GetImageSize related Bug Type: Bug Bug description:getimagesize() incorrectly identifies files as ICO which aren't Description: When certain types of files are uploaded, including .MPGs, getimagesize() incorrectly identifies them as ICOs with a MIME type of 'image/vnd.microsoft.icon'. I suspect certain files probably have embedded icons in them, which is what PHP is detecting and reporting, but the actual file isn't an ICO. A ~500K sample file can be found here: http://www.smugmug.com/img/video/problem/php-getimagesize.mpg Expected result: I'd expect FALSE to return, since this isn't a picture and isn't a valid type PHP knows about. Actual result: -- It returns this array: array(0 => 45, 1 => 82, 2 => 17, 3 => 'width="45" height="82"', 'bits' = 65023, 'mime' = 'image/vnd.microsoft.icon'); -- Edit bug report at http://bugs.php.net/bug.php?id=54723&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54723&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54723&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54723&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54723&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54723&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54723&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54723&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54723&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54723&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54723&r=support Expected behavior: http://bugs.php.net/fix.php?id=54723&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54723&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54723&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54723&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54723&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54723&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54723&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54723&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54723&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54723&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54723&r=mysqlcfg
Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries
Edit report at http://bugs.php.net/bug.php?id=53458&edit=1
ID: 53458
Comment by: don at smugmug dot com
Reported by: don at smugmug dot com
Summary:Non-linear performance degradation on certain
prepared SELECT queries
Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
FYI, setting PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to true/false didn't
have a large impact. Still ~10X slower than any of the other methods
either way. (Buffered was slightly faster)
Previous Comments:
[2010-12-02 23:39:10] don at smugmug dot com
Here's my PHP build configuration:
'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-
dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--
enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-
curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-
bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl'
'--with-mysqli=mysqlnd'
[2010-12-02 23:29:50] don at smugmug dot com
Description:
When retrieving results from prepared PDO statements against MySQL, we
get
performance that diverges from expected by 10X or more on results as low
as 1
rows. This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.
The attached script provides two PDO prepared approaches
('row-prepared', default,
and 'all-prepared') as well as a variety of control methods that use
non-prepared
PDO queries, straight MySQL, and prepared queries using MySQLi. Only
PDO with
prepared queries exhibits the problem.
If the query is broken up into chunks that return 1000 rows or less
prior to
execution, then combined afterwards in PHP, performance is as expected.
Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz
Expected result:
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should
return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).
Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in
~6s instead of ~0.5s
--
Edit this bug report at http://bugs.php.net/bug.php?id=53458&edit=1
Bug #53458 [Com]: Non-linear performance degradation on certain prepared SELECT queries
Edit report at http://bugs.php.net/bug.php?id=53458&edit=1
ID: 53458
Comment by: don at smugmug dot com
Reported by: don at smugmug dot com
Summary:Non-linear performance degradation on certain
prepared SELECT queries
Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Here's my PHP build configuration:
'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-
dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--
enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-
curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-
bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl'
'--with-mysqli=mysqlnd'
Previous Comments:
[2010-12-02 23:29:50] don at smugmug dot com
Description:
When retrieving results from prepared PDO statements against MySQL, we
get
performance that diverges from expected by 10X or more on results as low
as 1
rows. This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.
The attached script provides two PDO prepared approaches
('row-prepared', default,
and 'all-prepared') as well as a variety of control methods that use
non-prepared
PDO queries, straight MySQL, and prepared queries using MySQLi. Only
PDO with
prepared queries exhibits the problem.
If the query is broken up into chunks that return 1000 rows or less
prior to
execution, then combined afterwards in PHP, performance is as expected.
Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz
Expected result:
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should
return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).
Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in
~6s instead of ~0.5s
--
Edit this bug report at http://bugs.php.net/bug.php?id=53458&edit=1
[PHP-BUG] Bug #53458 [NEW]: Non-linear performance degradation on certain prepared SELECT queries
From:
Operating system: CentOS 5.5
PHP version: 5.3.3
Package: PDO related
Bug Type: Bug
Bug description:Non-linear performance degradation on certain prepared SELECT
queries
Description:
When retrieving results from prepared PDO statements against MySQL, we get
performance that diverges from expected by 10X or more on results as low as
1
rows. This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.
The attached script provides two PDO prepared approaches ('row-prepared',
default,
and 'all-prepared') as well as a variety of control methods that use
non-prepared
PDO queries, straight MySQL, and prepared queries using MySQLi. Only PDO
with
prepared queries exhibits the problem.
If the query is broken up into chunks that return 1000 rows or less prior
to
execution, then combined afterwards in PHP, performance is as expected.
Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz
Expected result:
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should
return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).
Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in
~6s instead of ~0.5s
--
Edit bug report at http://bugs.php.net/bug.php?id=53458&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53458&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53458&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53458&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53458&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53458&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53458&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53458&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53458&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53458&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53458&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53458&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53458&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53458&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53458&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53458&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53458&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53458&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53458&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53458&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53458&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53458&r=mysqlcfg
#49366 [NEW]: json_encode incorrectly escapes slashes (/)
From: don at smugmug dot com
Operating system: CentOS 5.3
PHP version: 5.3.0
PHP Bug Type: JSON related
Bug description: json_encode incorrectly escapes slashes (/)
Description:
When given a string with slashes in it, despite the JSON docs suggesting
that's legal, json_encode escapes them anyway.
http://www.json.org/ says "any-Unicode-character-except-"-or-\-or
control-character"
JSONLint at http://www.jsonlint.com/ also validates slashes that aren't
escaped as valid.
This adds response weight, and makes further processing much more
complex.
Reproduce code:
---
$vars['url'] = "http://www.example.com/";;
echo json_encode($vars);
Expected result:
{"url":"http://www.example.com/"}
Actual result:
--
{"url":"http:\/\/www.example.com\/"}
--
Edit bug report at http://bugs.php.net/?id=49366&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49366&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49366&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49366&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49366&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49366&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49366&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49366&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49366&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49366&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49366&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49366&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49366&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49366&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49366&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49366&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49366&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49366&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49366&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49366&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49366&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49366&r=mysqlcfg
