pein0119

Why objects (usually) use less memory than arrays in PHP

This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)

The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array part of it away. So how does that work?

The key here is that objects usually have a predefined set of keys, whereas arrays don't:

pein0119

upstream backend {
  server unix:/var/run/domain.sock;
}

server {
	listen 80 default;
	server_name domain.com;
	rewrite        ^ https://$server_name$request_uri? permanent;
}

pein0119

<?php

/*
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

pein0119

Latency Comparison Numbers
--------------------------
L1 cache reference                            0.5 ns
Branch mispredict                             5   ns
L2 cache reference                            7   ns             14x L1 cache
Mutex lock/unlock                            25   ns
Main memory reference                       100   ns             20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy              3,000   ns
Send 1K bytes over 1 Gbps network        10,000   ns    0.01 ms
Read 4K randomly from SSD*              150,000   ns    0.15 ms

pein0119

Nginx FastCGI response buffer sizes

By default when Nginx starts receiving a response from a FastCGI backend (such as PHP-FPM) it will buffer the response in memory before delivering it to the client. Any response larger than the set buffer size is saved to a temporary file on disk. This process is also explained at the Nginx ngx_http_fastcgi_module page document page.

Since disk is slow and memory is fast the aim is to get as many FastCGI responses passing through memory only. On the flip side we don't want to set an excessively large buffer as they are created and sized on a per request basis (it's not shared).

The related Nginx options are:

• fastcgi_buffering appeared in Nginx 1.5.6 (1.6.0 stable) and can be used to turn buffering completely on/off. It's on by default.
• [fastcgi_buffer_size](http://nginx.org/en/docs/http/ngx_ht

pein0119

function words($value, $words = 100, $end = '...')
{
	preg_match('/^\s*+(?:\S++\s*+){1,'.$words.'}/u', $value, $matches);
	if ( ! isset($matches[0]) || strlen($value) === strlen($matches[0])) return $value;
	return rtrim($matches[0]).$end;
}

/* 
Usage:

pein0119

package main

/*
 Channel and select {} illustrated by t9md
 ===========================================================
 sample program to understand goroutine communication via channel.

 based on go-tour's example
 https://tour.golang.org/concurrency/5
*/

pein0119

/*
   This is a go program to download pictures from a tumblr blog page.

   To Build:

       go build -o tumblr-download tumblr-download.go

   To Run:

       # download the photos on the first page of tumblr blog

pein0119

Channels Are Not Enough

... or Why Pipelining Is Not That Easy

Golang Concurrency Patterns for brave and smart.

By @kachayev

Intro

pein0119

#! /usr/bin/env python

import redis
import random
import pylibmc
import sys

r = redis.Redis(host = 'localhost', port = 6389)
mc = pylibmc.Client(['localhost:11222'])