On Tue, 06 Sep 2011 17:59:44 -0400, Jonathan M Davis <jmdavisp...@gmx.com> wrote:

On Tuesday, September 06, 2011 23:51:48 Marco Leise wrote:
Am 06.09.2011, 22:28 Uhr, schrieb Timon Gehr <timon.g...@gmx.ch>:
> On 09/06/2011 09:36 PM, notna wrote:
>> Sorry upfront, I didn't read this hole thread, so maybe I'm missing or
>> mixing something...
>>
>> How about a D binding for http://www.xmlsoft.org/ ?
>>
>> In other words, taking the "curl or sqlite3 path", something like
>> /etc/c/xml2
>
> That is about 4 times slower than the Tango XML parser:
>
> http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs
> -with-rapidxml/
You are so right, Timon. How deep is the trench between Phobos and Tango
devs? Tango's XML parser should really make it into Phobos.

A new std.xml is already in the works. It'll be range-based, unlike the Tango
parser. But there's no reason why Phobos shouldn't be able to have a
similarly-fast XML parser. As I understand it, the primary reason that the
current std.xml is slow is because it uses delegates quite a bit, but I
haven't used it myself, so I don't know all of the details.

No, the issue is, and always will be, buffer access. C's FILE * just doesn't provide anything decent. It's the primary motivation for wanting to revamp it. With slicing and copy avoidance (i.e. only read into a buffer, never copy out), we can achieve the same with Phobos, but I think we have to replace C's buffering system (at least for this usage).

Tango's I/O libraries use delegates and virtual functions galore. I think too big a stigma is attached to those. The difference between calling a virtual function/delegate and calling a normal function is very insignificant, the real savings for not using virtual functions is to allow inlining.

However, in this case, I/O is so diverse that you *need* polymorphism.

-Steve

Reply via email to