reading a XML file on every page execution - convert to PHP?

[Derik]

I've got a XML file I read using a file_get_contents and turn
into a simpleXML node every time index.php loads. I suspect this is
causing a noticeable lag in my page-execution time. (Or the wireless
where I'm working could just be ungodly slow-- which it is.)

Is reading a file much more resource/processor intensive than,
say, including a .php file? What about the act of creating a
simpleXML object? What about the act of checking the modification
date on a file? Does anyone have any advice, rumors or intimations
abotu the relative 'heaviness' of these tasks?

The simplest thing to do would be to serialize the xml file into
a variable in.php file for inclusion, then then check the .xml file's
modification date- and use the .xml only if it was newer. Otherwise
include the .php file, de-serialize the simplexml object and go,

Do I lose as much from the file datecheck and de-serializing as I
gain by ditching the file_get_contents? What if instead of
serializing, the datatree was created by outright assignment in
the .php? (losing some of the flexibility nuance of the simpleXML
object, sigh.)

Does include_once impose a processing penalty if the file has
already been included? Is it better to include_once() a required file
once at the top of a file with many possible functions, some of which
do not require the classes and methods you'd be including, or to
include_once many times within the file- specific to the sections that
need it? (A switch statement delineating a file's functions, for
example.)

Is there an internal PHP variable that lets you find out which
files /have/ been included?

If file A requires file B, and file B cannot load, file A suffers
a fatal error and cannot continue..
If file A includes file B, and file B cannot load, file A has a
very unhappy nonfatal error and continues.
If file A includes file B, and file B requires file C, if file C
cannot load, does file A continue executing? How far does the fatal
error reach?

This is a lot of work to go to for 1 XML file... but I'm trying
to abstract a lot of global config and form type creation data. (Some
pages might have 4 or 5 such files being loaded in.) Files that don't
change OFTEN- but do change often /enough/ (especially during
development but also after) that it'd be worth my time to
What about database queries? If a site only updates daily, I can
write the result of the frontpage's database queries to a .xml file
(or serialize into a .php file) every hour to reduce the number of
identical db queries index.php performs. That can be a fairly lengthy
tree- will the performance hit I take by reading a .xml file be worse
than the one I had doing DB queries? Serializing simpleXML object and
unserializing? 'Flattening' to an intermittent .php file with $var =
'value'?

I guess... I'm just kinda lost on the sort of overhead these
functions impose, and I'd like to know before I dive in. Anyone got a
clue?

-Derik

[Jerry Stuckle]

Derik wrote:

I've got a XML file I read using a file_get_contents and turn
into a simpleXML node every time index.php loads. I suspect this is
causing a noticeable lag in my page-execution time. (Or the wireless
where I'm working could just be ungodly slow-- which it is.)

Is reading a file much more resource/processor intensive than,
say, including a .php file? What about the act of creating a
simpleXML object? What about the act of checking the modification
date on a file? Does anyone have any advice, rumors or intimations
abotu the relative 'heaviness' of these tasks?

Two different things. Just reading a file does not include any parsing.
Including a php file requires the file be read then parsed. So
including is always going to be slower.

The simplest thing to do would be to serialize the xml file into
a variable in.php file for inclusion, then then check the .xml file's
modification date- and use the .xml only if it was newer. Otherwise
include the .php file, de-serialize the simplexml object and go,

Do I lose as much from the file datecheck and de-serializing as I
gain by ditching the file_get_contents? What if instead of
serializing, the datatree was created by outright assignment in
the .php? (losing some of the flexibility nuance of the simpleXML
object, sigh.)

The date check will also be quick. Deserialization takes some time,
also, but probably not as much as parsing the xml code in the first place.

As far as the assignment goes - it just depends on how much you're
doing. But it *probably* will be faster than the xml but slower than
serializing.

Does include_once impose a processing penalty if the file has
already been included? Is it better to include_once() a required file
once at the top of a file with many possible functions, some of which
do not require the classes and methods you'd be including, or to
include_once many times within the file- specific to the sections that
need it? (A switch statement delineating a file's functions, for
example.)

Just the overhead of PHP checking to see if the file has been included
or not. But that has to be done every time include_once() is called,
anyway.

Is there an internal PHP variable that lets you find out which
files /have/ been included?

No.

If file A requires file B, and file B cannot load, file A suffers
a fatal error and cannot continue..
If file A includes file B, and file B cannot load, file A has a
very unhappy nonfatal error and continues.
If file A includes file B, and file B requires file C, if file C
cannot load, does file A continue executing? How far does the fatal
error reach?

If file B required file C, and file C cannot load, you get a fatal error.

This is a lot of work to go to for 1 XML file... but I'm trying
to abstract a lot of global config and form type creation data. (Some
pages might have 4 or 5 such files being loaded in.) Files that don't
change OFTEN- but do change often /enough/ (especially during
development but also after) that it'd be worth my time to
What about database queries? If a site only updates daily, I can
write the result of the frontpage's database queries to a .xml file
(or serialize into a .php file) every hour to reduce the number of
identical db queries index.php performs. That can be a fairly lengthy
tree- will the performance hit I take by reading a .xml file be worse
than the one I had doing DB queries? Serializing simpleXML object and
unserializing? 'Flattening' to an intermittent .php file with $var =
'value'?

Personally, I'd use a database and skip the XML all together. And if
the data are called regularly, they will probably already be in the
database cache.

I guess... I'm just kinda lost on the sort of overhead these
functions impose, and I'd like to know before I dive in. Anyone got a
clue?

-Derik

Rule #1: Don't prematurely optimize.
Rule #2: If you have performance problems, find the cause.

In your case it could be the PHP code or the wireless connection. Find
out by putting a call to microtime() at the start and end of your
script. Subtract the two return values and print the amount of time it
takes to execute your code.

If you find it is too long, move the microtime() calls around to isolate
the code that's taking a long time.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Jeremy]

Jerry Stuckle wrote:

>
Rule #1: Don't prematurely optimize.
Rule #2: If you have performance problems, find the cause.

In your case it could be the PHP code or the wireless connection. Find
out by putting a call to microtime() at the start and end of your
script. Subtract the two return values and print the amount of time it
takes to execute your code.

If you find it is too long, move the microtime() calls around to isolate
the code that's taking a long time.

Profiling with microtime() is good for simple code and one-off
situations, but if you find yourself profiling a lot (which you should)
then installing an engine-level profiler (like xdebug) on your
development server can be extremely helpful. I have uncovered some
truly "WTF?" bottlenecks that I never would have thought to wrap in
microtime() calls.

http://pecl.php.net/package/Xdebug
To address the OP on a couple of points:

1) Last time I checked, SimpleXML objects cannot be serialized easily.
Even if they could, you wouldn't gain much time by using PHP
serialization over XML.

2) Unless your XML document is very large, the amount of time needed to
parse it is fairly negligible in the scope of a web request. Unless you
have a high-traffic site, it probably doesn't need to be a huge concern.
If your XML document IS very large, you should probably be using a
database instead, like Jerry suggested.

Here's another idea - what is your XML being used for? If you are
generating your page content from the XML, maybe you should think about
caching the end result of your index.php to static HTML and updating
this cache when the XML is changed. If you feel PHP is a performance
hit, why not bypass it entirely if the end result will always be
essentially the same?
Jeremy