Std.xml may have a druntime or compile issue on windows. csv formatted performance results, past into spreadsheet for better viewing.
"platform+compile","input","parse","slice parse","parse+dom","slice +dom","std.xml" "Ubuntu32+vbox+gdc2",0.012,0.072,0.052,0.1,0.069,0.092 "Ubuntu32+vbox+dmd2",0.008,0.058,0.041,0.085,0.057,0.078 "Windows7+vbox+dmd2",0.007,0.056,0.039,0.08,0.05,0.195 ,,,,,, ,"Percentage to 0.1",,,,, "Ubuntu32+vbox+gdc2",12,72,52,100,69,92 "Ubuntu32+vbox+dmd2",8,58,41,85,57,78 "Windows7+vbox+dmd2",7,56,39,80,50,195 The figure in the last column shows std.xml to be twice as slow on windows. All programs compiled to release. Each row is the execution times on same running process with different test, run 100s of times one after the other and averaged. (sxml.d) Input is going through buffer and filter, to examine every unicode character in the document as dchar. Parse - Core parser throughput, returning a copy of each XML node content, tag name, attribute value pairs. No data structures are created from parse items returned. (std.xmlp.coreparse) Slice-Parse - Parser throughput with string alias of in-memory document, much less re-allocations. (std.xmlp.sliceparse) No data structures are created from parse items returned. Parse+DOM - Create a DOM using immutable string duplicates of document content. Alias of tag names and attribute names. (std.xmlp.domparse) Slice+DOM - DOM using the same aliased strings of the in-memory document. (std.xmlp.slicedoc) Anomaly for std.xml Std.xml is actually pretty nifty on both Ubuntu compiles (dmd and gdc). Its about twice as slow with windows dmd, wheras the the other implementation tests are quite similar between Ubuntu and Windows. Std.xml does seem to slice the original in-memory string, on code inspection. Building its array dom model might be inefficient compared to the linked DOM model of the other DOM tests. I am not sure what the slow down on windows is due be. Any ideas please? As for being ready to submit these varied replacements for std.xml, I can say that I hope its getting close. The actual XML parsers and DOM are complete as far as I know, in that I am only making minor changes as I work on the Xpath 1.0 expression compile and execution and some XSLT, which are not yet test suite ready. The validating parser is 100% XML test suite compliant. I do not know what the submission process is. The issue with a parser that references the original in-memory image, is that when things get complicated with different source encodings, and compliance source line end substitutions, entity replacements, character and standard entity replacements in content and attributes, this tends to replace much more of the original source, so the speed advantage diminishes. Also the entire document stays in memory till the last reference is garbage collectable. Its all on dsource.org/xml/trunk/ Michael Rynn.