SPL – Standard PHP Library

I’ve been looking at SPL for some time now.  On one hand, it’s a new addition to PHP core (since version 5.3), so I know how to work without it.  On the other hand, it provides standardized solutions for common problems, and that should be enough reason to start using it.  However, today I came across an interesting article that provides even more reason to use SPL.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage:

$startMemory = memory_get_usage();
$array = range(1, 100000);
echo memory_get_usage() - $startMemory, ' bytes';

How much would you expect it to be? Simple, one integer is 8 bytes (on a 64 bit unix machine and using the long type) and you got 100000 integers, so you obviously will need 800000 bytes. That’s something like 0.76 MBs.

Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB – eightteen times more than we estimated.

[…]

But if you do want to save memory you could consider using an SplFixedArray for large, static arrays.

Have a look a this modified script:

$startMemory = memory_get_usage();
$array = new SplFixedArray(100000);
for ($i = 0; $i < 100000; ++$i) {
    $array[$i] = $i;
}
echo memory_get_usage() - $startMemory, ' bytes';

It basically does the same thing, but if you run it, you’ll notice that it uses “only” 5600640 bytes. That’s 56 bytes per element and thus much less than the 144 bytes per element a normal array uses. This is because a fixed array doesn’t need the bucket structure: So it only requires one zval (48 bytes) and one pointer (8 bytes) for each element, giving us the observed 56 bytes.

For years I’ve been suffering from PHP’s memory hunger. I’ve had to optimize the code around smaller memory footprints, unset variables, and do all sorts of other messy things, that I normally wouldn’t have in a high-level programming language like PHP. With SPL, it seems, there is more help on the horizon.

Color builder for 256-color terminal

Color builder for 256-color terminal

With most Linux terminals now supporting 256 colors, a tool like this one is mighty useful in building the escape sequences.  For off-line use, all code is available in GitHub repository, and all logic behind the calculations is explained in this Habrahabr post (albeit, in Russian).

LinkedIn “improved” profile

Today I got an email from LinkedIn, telling me that I am about to get an improved profile.

On December 11, 2012, you’ll be getting the new LinkedIn profile, which has a simplified design, provides deeper insights, and surfaces new ways to connect and build relationships. You’ll also be one of the first to preview a new way to showcase rich content on your profile — like presentations, videos, documents, and more.

But it’s not only the new functionality, some of the old functionality will be removed:

Now there are more ways than ever to tell your professional story on LinkedIn, and we’re excited for you to try them out. As we roll out these changes, we’ll also be streamlining our app offerings, so the following LinkedIn apps will no longer be supported on the homepage or profile as of December 11:

  • Blog Link
  • GitHub

Unfortunately, these are the only two applications that I am interested in.  As a blogger, I want to have my blog’s RSS feed broadcast to LinkedIn.  And as a developer, I can’t think of a better way than GitHub profile to showcase my work at LinkedIn.

I wonder what bits of new functionality will allow to compensate for this gaping hole…