CodeFucker.com

Столкнулся с проблемой, при попытке заапдейтить большой массив айдишек. Searchd ругается на 8кб с копейками запрос и клозит соединение.. Решение - разбить массив айди на несколько частей

Например вот так:

/*................................*/
            if(count($id) > 500) {
                $id = array_chunk($id, 500, true);
                foreach($id as $v)
                    $cl->UpdateAttributes('shop', array($this->table), $v);
            } else
                $cl->UpdateAttributes('shop', array($this->table), $id);
/*................................*/

<?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).

Перенапрягся в тренажерном зале так, что не мог уснуть 3 ночи. Чугунная бошка+антибиотики сделали свое дело, неделя пролетела без работы..

Вот к чему приводит сранная безвылазная сидячка за компом.

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

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

# 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().