Изпечатай

[neter]

Как се тества бързодействие на php скрипт?

Аз ползвам този клас

Код

GeSHi (PHP):
<?php
 
class timer
{
	var $start;
	var $pause_time;
 
	/*  start the timer  */
	function timer($start = 0)
	{
		if($start) { $this->start(); }
	}
 
	/*  start the timer  */
	function start()
	{
		$this->start = $this->get_time();
		$this->pause_time = 0;
	}
 
	/*  pause the timer  */
	function pause()
	{
		$this->pause_time = $this->get_time();
	}
 
	/*  unpause the timer  */
	function unpause()
	{
		$this->start += ($this->get_time() - $this->pause_time);
		$this->pause_time = 0;
	}
 
	/*  get the current timer value  */
	function get($decimals = 8)
	{
		return round(($this->get_time() - $this->start),$decimals);
	}
 
	/*  format the time in seconds  */
	function get_time()
	{
		list($usec,$sec) = explode(' ', microtime());
		return ((float)$usec + (float)$sec);
	}
}
 
?>

Използва се така

Код

GeSHi (PHP):
<?php
 
include('път/до/файла/с/класа'); //класът може да се плесне и директно на мястото на този include
$timer = new timer(1);
 
ТВОЯТ КОД
 
echo $timer->get();
?>

Удобството да се прави с клас е, че много лесно можеш да засечеш времето за изпълнение на което и да е парче код, намиращо се между създаването на обекта $timer и извеждането на резултата.

[b2l]

@neter много благодаря .

[clovenhoof]

Спорен въпрос е дали решението на borovaka или на ivo3d е най-бързо, така че изборът при писане на код е хубаво да падне на някое от тези две решения - не случайно това са стандартните начини за извършване на въпросното действие. Няма нужда да се прави сравнение между тези две решения - натоварването и скоростта ще са толкова близки, че е въпрос на лична преценка на програмиста кое от двете ще му прилегне по-добре в кода. И все пак, не трябва да се забравя, че for и while циклите не са напълно взаимозаменяеми, но в конкретната ситуация няма проблем.
Моето решение е най-бавно (почти двойно по-бавно, което в случая е около 3/10000 разлика, но ако повторим действието много пъти, почти двойната разлика почва да има значение), и както казах, е само за спорта (да попълним и алтернативната графа) или ако по някаква неведома причина програмистът не може или не иска да се обърне към стандартните цикли

Аз сравних твоето решение с това на боровака.
Сега погледнах това на ivo3d и аз лично бих избрал неговото.

В C помня че do/while беше с най-добро бързодействие. Също има значение в предиката дали ще се сравнява с 0 или с някакво число. С 0 е по-бързо. Pre increment e за предпочитане пред post increment. Това обаче за C, а в РНР предполагам тези неща не важат.

[thecharge]

Че то кой пита как става проверката? Аз знам как става проверката...

Как се тества бързодействие на php скрипт?

... изтрито ... Какъв е най-елемнтарният скрипт за бързодействие, а имено нещо от сорта на:

Код

GeSHi (PHP):
<?php 
$start = microtime();
$start = explode(' ',$start);
$start = $start[1] + $start[0]; 
 
 
 
//тук се изпълнява скрипта
 
 
 
$end = microtime();
$end = explode(' ',$end);
$end = $end[1] + $end[0]; 
$response= ($end - $start); 
echo number_format($response, 4, '.', '').' секунди'; 
?>
 

... изтрито ...
П.С. За по кратко може само:

Код

GeSHi (PHP):
<?php 
function measure()
{
	$a = microtime();
	$a = explode(' ',$a);
	$a = $a[1] + $a[0];
	return $a;
}
$start = measure();
 
 
 
//тук се изпълнява скрипта
 
 
 
 
$end = measure(); 
$response= ($end - $start); 
echo number_format($response, 4, '.', '').' секунди'; 
?>
 

редакция от neter: Редактирано, съгласно т.6 от правилата на форума

[SmashThePain]

Ако ще се прави с премахване на елементи от масива,  което не е хубава практика, доста по-добре да се ползва pop вместо shift. Ако някой имплементира shift с константно време ще го поздравя. Вероятно хората от PHP им е през оная работа за паметта и имплементацията на shift инкрементира указателя с единица. Такова фрагментиране на паметта е опасно, особено когато се разполага с малко памет...

Премахването на елементи от масиви е много много лоша практика в случая. Това се предполага че ще бъде някаква вълшебна utility функция, която трябва да приема като аргумент масив и на изхода да връща асоциативен масив. Та по идея масивите е хубаво да се предават по референция не по стойност. От тук следва, че ще се модифицират данни на потребителя, което е неприемливо, когато си говорим за API.

[neter]

Тъй като в случая става дума за действия с данни, на практика най-доброто, което може да се направи като оптимизация, е процесът да си остане в базата данни (където би трябвало да седят данните), вместо да се извежда в PHP. С това ще постигнем разтоварване на паметта и много по-бърз процес на обработка.
Тъкмо напоследък се занимавам с обработката на една идея, за целите на която имах нужда от скрипт, който да обхожда голямо количество данни. Данните ми седят в MySQL и по инерция списах обхождането на PHP, вземайки си със заявки на части данните, за да ми стигне паметта. Само че се оказа, че така ще отнеме необозримо много време, и докато бях зациклил над варианти как да го оптимизирам, един колега ми зададе хубавия въпрос "А защо не го правиш директно в базата?". Нямах отговор поради каква причина не го правя и реших да пробвам. Резултатът беше, че тестовите данни, с които си пробвам скрипта и които са много по-малко от реалните данни, скриптът с PHP минаваше за 4 минути, а подобен алгоритъм със същите данни, но реализиран със SQL, минаваше за 5 секунди. В крайна сметка (то пак по негова идея) минах на съвсем друг алгоритъм (още по-бърз) за обхождане и от две седмици насам правя обработката на реалните данни, подготвил съм се да приключа след някой и друг месец, и не мога да си представя колко време щеше да му трябва, ако бях останал на реализация с PHP. Както стана дума и в една друга тема, всеки език с целите си. Когато става дума за обхождания на данни, езикът за това е SQL, мястото е базата данни и всяка друга реализация е излишно губене на време и ресурси

[Naka]

Искам само да добавя, че от това с какъв тип цикъл ще се обхожда масива (for, foreach/while), зависи от това дали индексите в източника масив ще са подредени и поредни.
например  при това индексите вървят 0,1,2,3,4,5....:

Код:

[0] => id
 [1] => 1
 [2] => sort
 [3] => asc
 [4] => page
 [5] = > 123

и затова може да се обхожда с for ($i = 0; $i < count($array); $i = $i+2)

но такъв масив спокойно може да изглежда и така:

Код:

[0] => id
 [1] => 1
 [3] => sort
 [5] => asc
 [444] => page
 [445] = > 123

тогава такова обхождане с 'for' би било неправилно. Но ако се обхожда с  'foreach' или 'while' няма да има проблеми.
Много пъти ми се е случвало входящият масив да се получава в резултат на някакви предварителни обработки и да нямам 100% сигурност, че индексите ще са подредени и поредни. Затова най-сигурното е обхождане с 'foreach' или 'while' . В php всички масива са асоциативни. И входящият масив също ти е  асоциативен.

 

[SmashThePain]

@Naka това само в език от високо ниво може да стане. Няма ясно разграничаване между масив и хеш таблица. Ако правя API за масиви, проблемът със sparse arrays няма да е мой проблем. Ако някой подава подобни масиви има сериозен проблем с четенето и разбирането на API-то.

Итераторите като foreach обикновенно са доста по-тежки от един нормален for цикъл. За PHP не мога да говоря в дълбочина, но за JavaScript мога. Та в JavaScript енджините имат оптимизации когато говорим за обхождане с for цикъл и последователни числови индекси. Същото ако го направиш с for-in цикъл нещата ще двойно по-бани.
В примера тук дори for цикъла може да се оптимизира, като се кешира стойността на `count' вместо да се извиква на всяка итерация.

Щях да те питам, кога ти се е налагало да итерираш масив с разбъркани индекси?

[VladSun]

Код

GeSHi (PHP):
function get($key, &$input) {
  $keys = array_flip($input);
  return $input[$keys[$key] + 1];
}
 

[VladSun]

Всъщност не е добра идея - потребителски дефинираната информация може да "презапише" ключовете при array_flip(). Освен това array_flip би могла предизвика E_NOTICE за невалидните ключове дефинирани от информационната част.

[nask00]

Как се тества бързодействие на php скрипт?

С time()