Archive for the ‘PHP’ Category

PHP is a bad programming language

20. May 2011

4 Comments »

Recently I was having a discussion with a friend who insisted PHP is a bad programming language. His main argument was that PHP makes it easy for crappy programmers to write crappy code, therefore PHP is a bad programming language. I will admit, crappy programmers can write crappy code in PHP – but that does not make it a valid metric for comparing languages. In fact, crappy programmers can write crappy code in ANY language.

Lets take a look at C – an old and well respected programming language. While it is indeed very fast, the amount of built in functions are minimal. In PHP, if I want to sort an array, I can simply call the sort() function and it will use a fairly optimal and non-intuitive sorting algorithm, quick sort which runs in O(n*log n) time. Where as a crappy C programmer might write a more intuitive sorting algorithm, selection sort, which yields a O(n2) time. Therefore C is a crappy programming language because the programmer wrote a crappier algorithm. Or is it that C is a better programming language because it makes it hard for crappy programmers to write bad code?

What about automobiles? Cars make it really easy for crappy drivers to get into accidents. Thus driving an automobile is a bad mode of transportation.

What it really comes down to, is that people use the best tool for the job.

Array vs SplFixedArray

1. February 2011

1 Comment »

PHP offers eight primitive types to the user. One of them being an array. An interesting aspect of PHP arrays is that they are allocated dynamically. Thus, the following code is perfectly acceptable:

<?php
$arr = array(1, 2, 3, 4);
$arr[50] = 50;

The first line set the first four indexes to one through four respectively. This creates an array of size four. The second line sets index fifty to the value fifty augmenting the array size by one. Indexes five through forty nine do not exist, and attempting to access a non existing element will only raise an E_Notice level error message. The dynamic allocation of arrays allows programmers to ignore out of bounds exceptions, segmentation faults, and hours of debugging, but it also leads to a slower write time because the memory locations needed to hold the new data is not already allocated.

The Standard PHP Library offers a SplFixedArray object that pre-allocates the necessary memory thereby solving the issue of slower write times.

<?php

$array = new SplFixedArray(5);
print_r($array);

Which results in (a pre-allocated array)

SplFixedArray Object
(
[0] =>
[1] =>
[2] =>
[3] =>
[4] =>
)

Creation Time

To verify this, I ran a test that writes data to an array and an SplFixedArray and measures the time for different amounts of elements.

<?php

for($size = 1000; $size < 100000; $size *= 2) {
  $f = $size;
  for($t = microtime(true), $a = array(), $i = 0; $i < $size; $i++) {
    $a[$i] = NULL;
  }
  $f .= "," . (microtime(true) - $t) . ",";

  for($t = microtime(true), $a = new SplFixedArray($size), $i = 0; $i < $size; $i++) {
    $a[$i] = NULL;
  }
  $f .= (microtime(true) - $t) . "\n";
  file_put_contents("./data.csv", $f, FILE_APPEND);
}

Write Time

It is clear that the SplFixedArray has faster a write time. However, there is a significant overhead when an object is created. To test this, I ran the same test but each time I created a new data structure. From the plot, we can see that creating an array has minimal overhead, whereas creating a new SplFixedArray object and allocating the memory takes a significant more amount of time.

<?php

$elements = 20;

for($size = 1000; $size &lt; 100000; $size *= 2) {
  $f = $size;
  for($t = microtime(true), $i = 0; $i < $size; $i++) {
    for($j = 0,$a = array(); $j < $elements; $j++ ) {
      $a[$i] = NULL;
    }
  }
  $f .= "," . (microtime(true) - $t) . ",";

  for($t = microtime(true), $i = 0; $i &lt; $size; $i++) {
    for($j = 0, $a = new SplFixedArray($elements); $j < $elements; $j++) {
      $a[$j] = NULL;
    }
  }
  $f .= (microtime(true) - $t) . "\n";     file_put_contents("./data.csv", $f, FILE_APPEND);
}

Memory Footprint

Lastly I wanted to see how the memory usage differs between each data structure.

<?php

for($size = 1000; $size < 100000; $size *= 2) {

  $f = $size . ",";

  $t = memory_get_usage();
  for($a = array(), $i = 0; $i < $size; $i++) {
    $a[$i] = NULL;
  }

  $f .= (memory_get_usage() - $t) . ",";

  $t = memory_get_usage();
  for($a = new SplFixedArray($size), $i = 0; $i < $size; $i++) {
    $a[$i] = NULL;
  }

  $f .= ($t - memory_get_usage()) . "\n";

  file_put_contents("./data.csv", $f, FILE_APPEND);
}

Conclusion

The conclusion is one typical of Computer Science, trade-offs. If you are in an environment where you will need a few arrays with predetermined sizes, the SplFixedArray is the best choice. However, if you will be creating numerous arrays, or the size is unknown, then it is probably better to use the native PHP array.

Coding on the Cloud

12. January 2011

No Comments »

A couple weeks ago I wrote about my experience using the Cr-48 for a week. The conclusion was that the Cr-48 was not ready for John the programmer, but could potentially be the main platform for John the student. This wasn’t because of ChromeOS, but it was due to the lack of third party software for developers, namely an integrated development environment. In my search for a cloud IDE I stumbled across Mozilla Skywriter (formally known as Bespin), Kodingen, and Cloud9IDE. Although Kodingen seems to be the most advanced, its not opensource. Skywriter is pretty freaking awesome, and I am super excited that Skywriter and Cloud9IDE have teamed up to bring coding to the cloud.

Earlier today @cloud9ide announced a closed beta, with Cr-48 users having preference. I immediately took advantage of the opportunity and signed up. An hour later, my account was approved and I was coding on the cloud.

The layout looks like a typical IDE, it offers syntax highlight for JavaScript, CoffeeScript, CSS, (X)HTML, XML, Python, and PHP. It comes bundled with several different themes, a built in JavaScript debugger, a command line interface, and full support for git. It also appears to work with node.js, a technology I have yet to fully explore.

The motto is “A JavaScript IDE for JavaScripters by JavaScripters,” which is great, but I’m PHPer. I would love to see support for pushing files to my server/private cloud using ftp/sftp rather than my public GitHub repository.

This project looks very promising, and I look forward to watching the continual development of Cloud9IDE. Keep up the good work guys.