On Tue, Aug 28, 2012 at 7:18 PM, Adam Richardson <simples...@gmail.com> wrote:
> On Tue, Aug 28, 2012 at 7:39 AM, Matijn Woudt <tijn...@gmail.com> wrote:
>> On Tue, Aug 28, 2012 at 3:49 AM, Adam Richardson <simples...@gmail.com>
>> wrote:
>>> On Mon, Aug 27, 2012 at 6:54 PM, Matijn Woudt <tijn...@gmail.com> wrote:
>>>> On Mon, Aug 27, 2012 at 10:56 PM, Haluk Karamete
>>>> <halukkaram...@gmail.com> wrote:
>>
>> First of all, I believe PHP is smart enough to not generate bytecode
>> for functions that are not used in the current file. Think about the
>> fact that you can write a function with errors, which will run fine
>> until you call the function. (except for syntax errors).
>
> I believe this is untrue. PHP generates the bytecode and then parses
> the bytecode per request to generate the userland infrastructure,
> including classes and functions, for the entire include file. During
> the generation of bytecode, PHP doesn't know apriori which functions
> will be called at runtime. I suspect if you asked for confirmation of
> this on the internals list, they'd confirm this. In terms of errors,
> there are certainly different stages that errors can occur, and what
> you're referring to are runtime errors. Runtime errors don't
> necessarily show up in every possible execution branch. That doesn't
> mean that PHP didn't generate the code for the userland functionality.
>
>> The speed difference between loading 5K file or 50K file (assuming
>> continuous blocks) is extremely small. If you split this library, you
>> would have PHP files that require you to load maybe 3 or 4 different
>> files to have all their functions.
>
> Here's where I believe we have a communication issue. I never spoke of
> splitting up the library into 3 or 4, or any number of different
> files. The opening post states that only 10% of the pages need the
> library. I suggested that he only include the library in the 10% of
> the pages that need the library. That said, it's possible I
> misinterpreted him.
I interpreted it as: I have a 50K library, and some files only use
10%, some use 20% and some 30%. To be able to include it separately,
you would need to split and some would need to include maybe 3 or 4
files.
>
> I will say that I do disagree with your analysis that difference
> between loading a 5K or 50K php file is extremely small. So I just put
> this to the test.
>
> I created a 5K file and a 50K file, both of which have the form:
>
> function hello1(){
> echo "hello again";
> }
>
> function hello2(){
> echo "hello again";
> }
>
> etc.
>
> I have XDegub installed, have APC running, warmed the caches, and then
> test a few times. There results all hover around the following:
>
> Including the 5K requires around 50 microseconds. Including the 50K
> requires around 180 microseconds. The point is that there is a
> significant difference due to the work PHP has to do behind the
> scenes, even when functions (or classes, etc. are unused.) And,
> relevant to the dialog for this current thread, avoiding including an
> unused 50K PHP on 90% of the pages (the pages that don't need the
> library) will lead to a real difference.
>
> Adam
Finally, you're the first one that actually has measured something.
You should redo your test with real world files, because in real world
functions aren't that small.
In functions with more lines (say ~100 lines per function), you'll see
a different ratio between 5k and 50k. In my tests it is:
- 5K: 22ms
- 50K: 34 ms
When I create files that only contain 1 function, with just a number
of echo "Hello world"; lines until 5k or 50k, the results are:
- 5K: 15 ms
- 50K: 17 ms
Cheers,
Matijn
Ps. Code used:
<?php
$time_start = microtime(true);
include '5k.php'; // 5k.php or 50k.php
$time_end = microtime(true);
echo ($time_end - $time_start)."s";
?>
System specs:
Ubuntu 12.04 LTS with Apache 2.2.22 and PHP 5.3.10 default config with
no cache etc.
AMD Phenom X4 9550 (2.2GHz)
4 GB DDR2-800
Disk where PHP files at: WD 500GB with average read speed of 79.23
MB/s (as Measured with hdparm)
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
