Description:
------------
I keep big multidimensional arrays serialize()'d into strings in
database.
After upgrade from 4.3.9 -> 4.3.10 I noticed, that unserialize()
function on some of them work even 20 times slower. On other the
slowdown is minimal. 

Reproduce code:
---------------
<?
function getmicrotime() 
{ 
    list($usec, $sec) = explode(" ", microtime()); 
    return ((float)$usec + (float)$sec); 
} 

$f=fopen("serialized.txt","r");
$l1=fgets($f,1000000);
fclose($f);

$t1=getmicrotime();
$a=unserialize($l1);
echo(getmicrotime()-$t1);
?>

The tested "serialized.txt" file can be downloaded from
http://ap.aptus.pl/serialized.txt

Expected result:
----------------
The above script working as fast as in 4.3.9

Actual result:
--------------
The script works about 20x slower.

Pretty sure we're getting hit by this as well. We use serialize a lot
(memcached), and upgrading from PHP 4.3.9 to 4.3.10 tripled our servers'
load averages.

i use vbulletin 3.0.5. the forumcache is also unserialized.
i tracked this with the nusphere profiler.

with php 4.3.9 (or 5.0.2) it takes around 300ms.
with php 4.3.10 (or 5.0.3) it takes 17s and more !!!

the cache is around 2.5 megs big ;(

I can confirm this problem from my experience with 4.3.10 and 5.0.3.

Unserialize() under the latest versions appears to be massively slower
than was previously so.

We have had wide reports of vBulletin installations running
significantly slower since we recommended that customers upgrade to
4.3.10 / 5.0.3.

Hoping for a quick resolution to this problem, as it affects so many
people so drastically.

The excessively high load average of a server recently updated to php
4.3.10 was driving me nuts.  This bug is critical for many php based
systems as drupal, vBulletin and others.

Gik.

Sorry to say... but abusing serialize for this is not a good idea in the
first place. It's not meant for storing data in this way in the first
place. But of course the slowdown shouldn't have been this much.

As far as I know, objects stored in shared memory using shm_put_var()
are stored serialized.  I haven't looked at the  sources yet, but the
problem affecting unserialize() should also degrade the performance of
shm_put_var() which is vastly used to store arrays or other objects in
shared memory for _quick_ access.  I don't know if there are other
functions which use this method internally.

I wouldn't call it an abuse to serialize and store an array with 1000
elements in shm, as this is a very efficient way to do data caching. 
The performance degradation is large enough to make a web server
collapse, because of the extra time required to process each request.

I would agree with what Gik just said.

To quote from the PHP manual: 
"serialize --  Generates a storable representation of a value"
Or later:
"serialize() returns a string containing a byte-stream representation of
value that can be stored anywhere.

This is useful for storing or passing PHP values around without losing
their type and structure."

I tried some comparisons a while back on different ways to store PHP
array data in a DB. I tried storing it in a form where I could run
eval($data) and it turned out to be a lot slower than
unserialize($data). (Perhaps this would be different given this bug).
serialize() seems to be ideal for this situation where large array or
object data is to be stored in a DB or shm.

So I was surprised that the usages outlined above are 'abuses', as they
seem to be using serialize() for exactly what it was intended for.
Perhaps the manual needs clarifying if this isn't the case?

It has been quite some time now and this is really an important bug to
fix. 

I understand that open source means that development is done when
someone feels like it, but as this is crumbling big shared hosting
solutions where sites run on this PHP which use unserialize() I really a
fix is developed soon. 

Comon devs, wake up and smell some coffee :)

I'd agree, this is a huge performance issue in 4.3.10/5.0.3 which really
needs to be fixed ASAP.  I've seen many servers with performance issues
because of this bug since upgrading PHP.

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Please try this with the next snapshot that is build at 19:30 GMT. I
made some changes to unserialize() that should have restored its
speed.

I've compiled the latest snapshot of PHP_4_3 and it seems to be behaving
much better on real-life applications (I haven't tried the test program
attached to this thread yet).  I'll keep testing for a few more days to
be sure the server's performance has returned to normal levels. 

Thanks for the prompt reaction.

I've tested the Win32 snapshot on my serialized data I attached to the
bug report and it seems that it works as fast as it used to work in
4.3.9.
Thanks for solving this problem!

This bug has been fixed in CVS.

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.