ID: 44125 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: XML related Operating System: Windows Vista PHP Version: 5.2.5 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2008-03-30 22:14:07] [EMAIL PROTECTED] 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-26 19:48:04] [EMAIL PROTECTED] 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-02-15 00:29:49] [EMAIL PROTECTED] 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-02-15 00:27:42] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=44125&edit=1
