note 97419 added to class.mysqli-result

From: Date: Mon, 19 Apr 2010 06:39:14 +0000
Subject: note 97419 added to class.mysqli-result
Groups: php.notes 
Request: Send a blank email to php-notes+get-168388@lists.php.net to get a copy of this message
Generally, it appears Mysqli OO vs Procedural style has no significant difference in speed, at least with the more generally used functions and methods (connect, close, query, free, etc). With the fetch_* family of functions and methods dealing with result rows, however, Procedural wins out. Averaging over a hundred or so tests with a result set of 180,000 records, and using mysqli_fetch_*() functions vs. their mysqli_result::fetch_*() counterpart object methods to read and iterate over all records, all of the mysqli_fetch_*() functions win by ~0.1 seconds less. This is interesting considering we're dealing with the same result object in both styles. This was using Vistax64, PHP5.3.2, Mysql 5.1.45, using a bit of this code: <?php // procedural - takes 0.1 seconds less than OO here $stopwatch = microtime(true); while($row = mysqli_fetch_assoc($result)){ ++$z; } echo microtime(true) - $stopwatch; // OO $stopwatch = microtime(true); while($row = $result->fetch_assoc()){ ++$z; } echo microtime(true) - $stopwatch; ?> ---- Server IP: 208.69.120.55 Probable Submitter: 66.25.188.193 ---- Manual Page -- http://www.php.net/manual/en/class.mysqli-result.php Edit -- https://master.php.net/note/edit/97419 Del: integrated -- https://master.php.net/note/delete/97419/integrated Del: useless -- https://master.php.net/note/delete/97419/useless Del: bad code -- https://master.php.net/note/delete/97419/bad+code Del: spam -- https://master.php.net/note/delete/97419/spam Del: non-english -- https://master.php.net/note/delete/97419/non-english Del: in docs -- https://master.php.net/note/delete/97419/in+docs Del: other reasons-- https://master.php.net/note/delete/97419 Reject -- https://master.php.net/note/reject/97419 Search -- https://master.php.net/manage/user-notes.php

« previous php.notes (#168388) next »