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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ezyang@php.net
New email:
PHP Version: OS:

 

 [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-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC