php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #44125 Doubled memory usage on XInclude with Unix-style filenames
Submitted: 2008-02-15 00:27 UTC Modified: 2008-04-07 01:00 UTC
From: ezyang@php.net Assigned:
Status: No Feedback Package: XML related
PHP Version: 5.2.5 OS: Windows Vista
Private report: No CVE-ID: None
View Developer Edit
 [2008-02-15 00:27 UTC] ezyang@php.net 
Description:
------------
On Windows, XML files with large amounts of XIncludes (such as the PHP Documentation Manual, where this bug was discovered) exhibit curious behavior when they were loaded with Unix-style paths: they appear to require double the memory than if they were loaded with Windows-style paths.

Reproduce code:
---------------
<?php

// note forward slashes
$file = 'C:/Users/Edward/phpdoc/manual.xml';
$dom = new DOMDocument();
echo "Loading XML\n";
$dom->load($file);
echo "Performing XIncludes\n";
$dom->xinclude();


Expected result:
----------------
With an external process manager (Task Manager or Process Explorer), memory usage should spike on $dom->load(), and then stay constant during XIncludes. XIncludes should be very quick.

Actual result:
--------------
XIncludes take a long time to run, and double the memory usage of php.exe.

A curious side-effect of this is that call to $dom->load() immediately after the offending XInclude is extremely slow. This can be from a completely separate process.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-02-15 00:29 UTC] ezyang@php.net 
P.S. There is a rather obvious (and effective) workaround for this: realpath($file) before passing it to DOMDocument::load(). However, in theory, such a call should not be necessary.
 [2008-03-26 19:48 UTC] rrichards@php.net 
Does this only occur on Vista? Running on XP, I cannot reproduce the 
issue. It runs just as quick using either notation. As for your "side-
effect" issue. Re-use the dom object causes the tree to be unloaded with 
the second load() call and takes a  while due to the size.

In any case, it is best to use file:///<windows path> for windows files 
as the paths do not conform well to uris. By using the file schema (note 
the 3 slashes), dom extension is able to know it is a file and 
automatically performs the real path call.
 [2008-03-30 22:14 UTC] ezyang@php.net 
rrichards, are you running this off of the phpdoc HEAD? The slowdown occurred with 1.36 of configure.php; later versions may have changed the format of manual.xml. It might be a Vista only issue.

> Re-use the dom object causes the tree to be unloaded with [snip]

What I don't understand, however, is how the DOM tree could persist across requests.

> In any case, it is best to use file:///<windows path> for windows files

I have never heard of this before. Do you mean I should use file:///C:\Users\Edward\... or file:///C:/Users/Edward/... ?
 [2008-03-30 22:34 UTC] rrichards@php.net 
I was trying phpdoc out of HEAD. So you can reproduce the issue using 
that specific version of configure.php against HEAD? I haven't yet been 
able to reproduce.

DOM tree doesn't persist. I took your statement as you tried to load 
right after performing xinclude.
using file:/// insures that the path is properly converted no matter 
which style you use.
 [2008-04-07 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Mar 10 21:01:30 2025 UTC