CodeFucker.com

Допустим нам нужно подключить exif к уже имеющейся сборке, без пересборки всего PHP целиком со всеми нужными расширениями и прочим гемороем. Для этого существует такое понятие как shared библиотека, которую можно скомпилировать отдельно и подключить к PHP. Один из вариантов описан тут, но существует способ побыстрей - при помощи phpize.
Качаем сорцы PHP той же версии что и стоит в данный момент, заходим в папку ext - тут то и лежат все расширения. Так как речь шла о exif’е, то нас интересует папка exif.
Собсна:

cd ext/exif
phpize
./configure [--help для прсомотра возможных опциональных параметров]
make
make install

Если установлено несколько версий PHP, есть хороший параметр

./configure --with-php-config=/path/to/php-config

Собрали расширение, скопировали в папку, указанную как extension_dir в php.ini (иногда посредством уличной магии копируется само куда надо), раскомментили/добавили строчку etension=exif.so все в том же php.ini и вуаля - все работает Если под веб - рестарт апача после всего этого дела.

Оказывается PHP не может работать с зип архивами длиннее 2х гб.. PHP собран с large file support’ом, zip_open возвращает 19 - ZIP_ER_NOZIP. Та же песня с unzip’ом консольным, но там все понятно, собран без поддердки больших файлов. Пробовал даж zlib пересобирать - не помогло.. Все это справедливо для redhat based оси, php 5.2.5, 5.2.6, 5.3.0alpha3-dev. Судя по багам, люди сталкивались только с проблемами на 64битках и большим кол-вом файлов в архиве Зато 7zip враппер на exec’ах работает отлично

<?php
$key = explode(' ', 'testword');
foreach($key as &$v) $v = trim($v);

foreach(array('store', 'brand') as $v){
    /*.......*/
}
print_r($key);
?>

Как может показаться в массиве $key должно быть ‘testword’ но это не так. Проблему решает только unset($v) после первого foreach’a.

Почему-то при изучении и работе с пхп в мане нираз не видел упоминаний про работу с большими файлами (2гб+), хотя оно там есть и по ошибке, выдаваемой интерпретатором (File size limit exceeded), этот ман не гуглится
Для работы с большими файлами требуется пересобрать PHP с флагами CFLAGS=”-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64″

CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" \
./configure .....

Ахтунг, если поддержка нужна для веба, необходимо также пересобрать апач и мод_ссл с теми же флагами. Для консоли сойдет пересобрать пхп в другое место
Интересный факт, что после сборки PHP с такими флагами, время работы с файлами увеличилось ровно в 2 раза, по сравнению со сборкой без флагов. Добавляем -O2 или -O3 к флагам и радуемся результату при -O3 работает чуть-чуть быстрей дефолтной сборки (gcc 4.1.1).

Прочитал тут недавно у одного адепта, что не имеет смысла оптмизировать строки и писать в ординарных кавычках, что лучше строить боинги которые видимо развалятся не взелетев с таким подходом ПОХАПЕ сам по себе гавноязык, который нужно оптимизровать везде насколько можно, если нужна максимальаня производительность, что особо сказывается на крупных проектах. Слово крупный тут не значит использование всевозможных фреймворков и больших денег за работу, слово крупный тут имеет смысл большой нагрузки, где каждый выигранный % производительности на счету.

Не поленился написать нубоскрипт, вот результаты:

# vars    time with "       time with '       performance
1         3.6974380016327   2.5139710903168   147.08%
2         6.0501251220703   5.0527441501617   119.74%
3         8.2543439865112   7.8380331993103   105.31%
4         10.672549962997   10.420034885406   102.42%
total     28.674457073212   25.824783325195   111.03%  

Отсюда видно, что максимальный отрыв наблюдается при подстановке 1ой переменной и даже при падении скорости при подстановке 4х переменных, общая производительность выше. Поэтому не ленитесь и пишите все строки сразу с 1ой кавычкой, тем более если нужно подставить всего 1ну переменную.
Continue reading »

Очень полезная и чесно пизженная функция с каментов на php.net с минимальными изменениями, помогает для отлова узких мест в скрипте и настройки производительности функций/методов

<?php
function debug() {
   static $start_time = NULL;
   static $start_code_line = 0;

   $call_info = array_shift( debug_backtrace() );
   $code_line = $call_info['line'];
   $file = array_pop( explode('/', $call_info['file']));

   if( $start_time === NULL ) {
       print 'debug '.$file.'> initialize'."\n";
       $start_time = time() + microtime();
       $start_code_line = $code_line;
       return 0;
   }

   printf('debug %s> code-lines: %d-%d time: %.4f mem: %d/%d KB'."\n", $file, $start_code_line, $code_line, (time() + microtime() - $start_time), ceil(memory_get_usage()/1024), ceil(memory_get_usage(1)/1024));
   $start_time = time() + microtime();
   $start_code_line = $code_line;
}
?>

Continue reading »

В ходе недавних тестов выявил, что memory_get_usage() не показывает используемую память под буфферизацию вывода MySQL в самом PHP скрипте, из-за чего вполне можно упереться в memory_limit и долго ругаться, почему вылетает скрипт, находясь далеко от мемори_лимита. (PHP 5.2.5)

Поэтому, чтобы не наступить на грабли, советую использовать mysql_unbuffered_query(). Это сократит время выполнения и потребляемые ресурсы скрипта.

Из минусов только отсутсвие возможности повторного mysql запроса до полной выборки предыдущего (так думает PHP и ругается по этому поводу :)), нельзя юзать mysql_num_rows() (замена SQL_CALC_ROWS, либо в скрипте по ходу выборки) и не будет пахать убер mysql_data_seek().