php-general Digest 29 Aug 2012 17:28:39 -0000 Issue 7942
Topics (messages 318914 through 318922):
Re: include selectively or globally?
318914 by: Matijn Woudt
318915 by: Matijn Woudt
318918 by: Adam Richardson
318921 by: David Harkness
Re: FoxPro Table Structure
318916 by: Bastien
Re: PHP to XLS Security Alert issue
318917 by: Matijn Woudt
318922 by: admin
Re: OT (maybe not): Drupal vs WordPress
318919 by: Larry Garfield
318920 by: Adam Richardson
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Tue, Aug 28, 2012 at 6:55 PM, David Harkness
<davi...@highgearmedia.com> wrote:
> On Tue, Aug 28, 2012 at 4:39 AM, Matijn Woudt <tijn...@gmail.com> wrote:
>>
>> First of all, I believe [A] 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. [B] (except for syntax errors).
>
>
> [B] negates [A]. PHP must either parse the file into opcodes or load them
> from APC and further execute the top-level opcodes. That means defining
> functions (not calling them unless called directly), constants, global
> variables, classes, etc. No amount of measuring is required to tell me that
> doing X vs. not doing X in this case clearly takes longer.
[B] does not negate [A]. There's a difference between parsing the
syntax and defining functions, classes constants and globals, and
generating bytecode. In a 'normal' file I guess syntax definitions are
only about 5% of the total contents, the rest can be ignored until
being called.
>
> Now, is that time significant enough to warrant the extra logic required? In
> my case, absolutely. We organize our library into many classes in multiple
> files. By using an autoloader, we simply don't need to think about it.
> Include bootstrap.php which sets up the autoloader and include paths. Done.
>
> In the case with a single 50k library file that is used on 10% of the pages,
> I'd absolutely require_once it only in the pages that need it without
> measuring the performance. It's so trivial to maintain that single include
> in individual pages that the gain on 90% of the pages is not worth delving
> deeper.
>
> Peace,
> David
>
Let me quote the OP, I think that suffices:
"When answering this question, please approach the matter strictly from
a caching/performance point of view, not from a convenience point of
view just to avoid that the discussion shifts to a programming style
and the do's and don'ts."
- Matijn
--- End Message ---
--- Begin Message ---
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)
--- End Message ---
--- Begin Message ---
On Tue, Aug 28, 2012 at 3:28 PM, Matijn Woudt <tijn...@gmail.com> wrote:
> On Tue, Aug 28, 2012 at 7:18 PM, Adam Richardson <simples...@gmail.com> wrote:
>
> 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 terms of redoing the test with "real world files", that's an
entirely different debate (and one I won't enter into at this time,
though this list has discussed this topic before, most recently in a
post Ted made talking about screen height.)
The point is, there is a real difference. The question remains if the
difference is enough to act on in future code bases (and I would say
yes if my tests showed this difference, you may say no.)
> 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
Those trends/results depend significantly on the contents of the
functions, too. The overly simplistic example we've used both helps
and hurts the analysis (I'll admit my example likely has more
functions than other 5K/50K files, and I suspect most functions
require more complicated work behind the scenes to build up than echo
statements.)
The point I'd make here is that it's very difficult to have apriori
knowledge of how something will perform without testing it.
> 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
Ummm... sure. What did you say about real world before :)
Have a nice day!
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
--- Begin Message ---
On Tue, Aug 28, 2012 at 12:11 PM, Matijn Woudt <tijn...@gmail.com> wrote:
> On Tue, Aug 28, 2012 at 6:55 PM, David Harkness
> <davi...@highgearmedia.com> wrote:
> > On Tue, Aug 28, 2012 at 4:39 AM, Matijn Woudt <tijn...@gmail.com> wrote:
> >>
> >> First of all, I believe [A] 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. [B] (except for syntax errors).
> >
> > [B] negates [A]. PHP must either parse the file into opcodes or load
> them
> > from APC and further execute the top-level opcodes. That means defining
> > functions (not calling them unless called directly), constants, global
> > variables, classes, etc.
>
> [B] does not negate [A]. There's a difference between parsing the
> syntax and defining functions, classes constants and globals, and
> generating bytecode. In a 'normal' file I guess syntax definitions are
> only about 5% of the total contents, the rest can be ignored until
> being called.
>
I won't claim a deep understanding of the PHP internals, but I have enough
experience with varied compiled and interpreted languages and using PHP and
APC that I'm confident that the process to include a file involves:
1. Load the opcodes
A. Either read the file from disk and parse the PHP into opcodes, or
B. Load the cached opcodes from APC.
2. Execute the top-level opcodes
Any syntax errors--even those in unreachable code blocks--will cause the
script to fail parsing. For example,
if (false) {
function foo() {
SYNTAX ERROR!
}
}
will cause the parse to fail even though the function cannot logically be
defined. PHP doesn't even get that far.
PHP Parse error: syntax error, unexpected T_STRING in php shell code
on line 3
> "When answering this question, please approach the matter strictly from
> a caching/performance point of view, not from a convenience point of
> view just to avoid that the discussion shifts to a programming style
> and the do's and don'ts."
While out of convenience you might be tempted to include the file in every
script, when considering performance alone you should include the file only
in those scripts that will make use of its contents.
Peace,
David
--- End Message ---
--- Begin Message ---
Bastien Koert
On 2012-08-28, at 11:52 AM, Floyd Resler <fres...@adex-intl.com> wrote:
> On Aug 28, 2012, at 11:32 AM, Paul M Foster <pa...@quillandmouse.com> wrote:
>
>> On Tue, Aug 28, 2012 at 10:46:24AM -0400, Floyd Resler wrote:
>>
>>> Is there a way in PHP to get the structure of a FoxPro table (using
>>> ODBC) without having to query the table? I know I can get it by
>>> getting a row from the table and using odbc_field_type but I'd rather
>>> not have to query an entire table since there is no LIMIT command in
>>> FoxPro. I've looked and looked and haven't found a solution.
>>>
>>> Thanks! Floyd
>>
>> FoxPro tables have a header which details the structure of the rows
>> which follow it. I've never written PHP code to do what you're asking,
>> but I did write a C program which will detail the header, dump the
>> records, output the table as SQL and a variety of other things,
>> depending on the command line switches. I generally use it *with* PHP,
>> using a system() call, capture the results, and then display them on
>> screen as needed. The code is on SourceForge. See:
>>
>> http://noferblatz.com/dbfsak.php
>>
>> If you download the code and need help, just let me know. I believe the
>> command line switch you're looking for is -i, as in:
>>
>> dbfsak -i mytable.dbf
>>
>> Paul
>>
>> --
>> Paul M. Foster
>> http://noferblatz.com
>> http://quillandmouse.com
>
> Paul,
> Thanks for the info. Unfortunately dbfsak won't work for me since I don't
> have direct access to the ForPro dbf files. I access them through an
> odbc-odbc bridge server.
>
> Thanks!
> Floyd
Could you do a query like
>
Select * from table where 1=2
That should only return the header row
Bastien
--- End Message ---
--- Begin Message ---
On Tue, Aug 28, 2012 at 5:56 PM, admin <ad...@buskirkgraphics.com> wrote:
> I am exporting to a XLS file and the file does export, but when I open the
> file Microsoft is giving a Excel Security Notice.
>
> I am sure there is something in the header that is missing or causing this
> problem.
>
>
>
> header("Pragma: public");
>
> header("Expires: 0");
>
> header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
>
> header("Content-Type: application/force-download");
>
> header("Content-Type: application/octet-stream");
>
> header("Content-Type: application/download");
>
> header("Content-Disposition: attachment;filename=list.xls");
>
> header("Content-Transfer-Encoding: binary ");
>
>
>
> I use pack() to write the labels, Numbers, data. If that could be the
> culprit.
>
> echo pack("sssss", 0x203, 14, $Row, $Col, 0x0);
>
> echo pack("d", $Value);
>
> I am running 5.2 on PHP and opening the document with 2010 Office on
> Windows.
I believe that's normal, and that it does that with any document
downloaded from the web.
I'm not sure if there's a workaround, but you should not ask that here
but on a Microsoft Office forum/list, or just ask the question to
Microsoft themselves.
- Matijn
--- End Message ---
--- Begin Message ---
-----Original Message-----
From: Matijn Woudt [mailto:tijn...@gmail.com]
Sent: Tuesday, August 28, 2012 3:55 PM
To: admin
Cc: php-gene...@lists.php.net
Subject: Re: [PHP] PHP to XLS Security Alert issue
> I believe that's normal, and that it does that with any document downloaded
> from the web.
> I'm not sure if there's a workaround, but you should not ask that here but on
> a Microsoft Office forum/list, or just ask the question to Microsoft
> themselves.
>
> - Matijn
>
> --
> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
> http://www.php.net/unsub.php
Matijn,
I understand YOU believe this is normal.
I am sorry you feel that way because the construction of the document is
exactly where the problem was resolved, and that is in PHP.
So asking in the PHP-List was the exact the place to post a question of
document construction using PHP. Yes understanding the document verification
methods of Microsoft helps but it is up to the DEVELOPER to put the correct
headers and content strings to make the document valid and that is what I was
asked.
Q: I am exporting to a XLS file and the file does export, but when I open the
file Microsoft is giving a Excel Security Notice. I am sure there is something
in the header that is missing or causing this problem?
--- End Message ---
--- Begin Message ---
On 8/20/12 3:36 AM, Simon Schick wrote:
One thing I also really like at the TYPO3-philolsophy: If someone
finds a security-issue he should immediately get in contact with the
developers (of the extension and the TYPO3 security team) and discuss
the issue with them. They decide how critical the bug is and will do a
hard work to get the fix as soon as possible. If it is a very critical
issue (someone could gain admin-access by something) they will send
out an email that there will be a bugfix coming out at next-coming day
at 9 o'clock GMT and everyone is advised to update his TYPO3-core or
the extension. This is something I really like! To be prepared for
some critical fix and knowing that (in a perfect case) no-one should
have heard about that issue before who wants to hack my website :)
Don't know if there's some similar security-policy in other
communities than this :)
Drupal's security process is substantially similar, and also follows
security best practices:
http://drupal.org/security-team
--Larry Garfield
--- End Message ---
--- Begin Message ---
On Tue, Aug 28, 2012 at 3:07 PM, Larry Garfield <la...@garfieldtech.com> wrote:
> Only semi-joking line that's been making the rounds lately:
>
> If you want to build a blog, use Wordpress.
> If you want to build Wordpress, use Drupal.
> If you want to build Drupal, use Symfony2.
Here's another semi-joking line :)
If build a blog using Wordpress, build Wordpress using Drupal, build a
Drupal using Symfony2, I'd feel the same way I feel after drinking
several beers, eating a pizza, snacking on some hot wings, and
polishing it all off with a banana split: bloated :)
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
--- End Message ---
