I have done some benchmarks of the D xml parsers alongside C/C++/Java parsers, and as you can see from the graphs, D is rocking with Tango!

http://dotnot.org/blog/index.php

I wanted to post to let the D community know that good language and library design can really make an impact.

As always, I am open to comments/changes/additions, etc.  I will be happy to run any other project code through the benchmark if someone submits a patch to me containing the code.

And Walter, I am trying to use "D Programming Language" everywhere I can :)

Cheers,
Scott Sanders

Nice work!


Sean

Scott Sanders wrote:
> I have done some benchmarks of the D xml parsers alongside C/C++/Java
> parsers, and as you can see from the graphs, D is rocking with Tango!
> 
> 
> http://dotnot.org/blog/index.php


Reddit link: http://reddit.com/r/programming/info/6bt6n/comments/

== Quote from Scott Sanders (scott@stonecobra.com)'s article
> I have done some benchmarks of the D xml parsers alongside C/C++/Java parsers, and as you can see from the
graphs, D is rocking with Tango!
> http://dotnot.org/blog/index.php
> I wanted to post to let the D community know that good language and library design can really make an
impact.
> As always, I am open to comments/changes/additions, etc.  I will be happy to run any other project code
through the benchmark if someone submits a patch to me containing the code. The charts look great.

I generally handle files that are a few hundred MB to a few gigs and I noticed that the input is a char[], do you also plan on adding file streams as input?

N/A

== Quote from N/A (NA@NA.na)'s article
> I generally handle files that are a few hundred MB to a few gigs and I noticed that the input is a char[], do you also plan on adding file streams as input?

I believe the suggested approach in this case is to access the input as a memory mapped file.  This does place some restrictions on file size in 32-bit applications, but then those are ideally in decline.


Sean

== Quote from Sean Kelly (sean@invisibleduck.org)'s article
> == Quote from N/A (NA@NA.na)'s article
> > I generally handle files that are a few hundred MB to a few gigs
and I noticed that the
> > input is a char[], do you also plan on adding file streams as
input?
> I believe the suggested approach in this case is to access the
input as a memory mapped file.  This does
> place some restrictions on file size in 32-bit applications, but
then those are ideally in decline.
> Sean

Any examples on how to approach this using Tango?

Cheers,
N/A

N/A Wrote:

> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
> > == Quote from N/A (NA@NA.na)'s article
> > > I generally handle files that are a few hundred MB to a few gigs
> and I noticed that the
> > > input is a char[], do you also plan on adding file streams as
> input?
> > I believe the suggested approach in this case is to access the
> input as a memory mapped file.  This does
> > place some restrictions on file size in 32-bit applications, but
> then those are ideally in decline.
> > Sean
> 
> Any examples on how to approach this using Tango?
> 
> Cheers,
> N/A
Should be able to:

auto fc = new FileConduit ("test.txt");
auto buf = new MappedBuffer(fc);
auto doc = new Document!(char);
doc.parse(buf.getContent());

That should do it.

> Should be able to:
> auto fc = new FileConduit ("test.txt");
> auto buf = new MappedBuffer(fc);
> auto doc = new Document!(char);
> doc.parse(buf.getContent());
> That should do it.

Thanks,

I was wondering on how to do it using the PullParser.

Cheers

N/A Wrote:

> 
> > Should be able to:
> > auto fc = new FileConduit ("test.txt");
> > auto buf = new MappedBuffer(fc);
> > auto doc = new Document!(char);
> > doc.parse(buf.getContent());
> > That should do it.
> 
> Thanks,
> 
> I was wondering on how to do it using the PullParser.
> 
PullParser is exactly the same, just swap Document!(char) with PullParser!(char).

Scott

Sean Kelly wrote:
> == Quote from N/A (NA@NA.na)'s article
> 
>>I generally handle files that are a few hundred MB to a few gigs and I noticed that the
>>input is a char[], do you also plan on adding file streams as input?
> 
> 
> I believe the suggested approach in this case is to access the input as a memory mapped file.  This does
> place some restrictions on file size in 32-bit applications, but then those are ideally in decline.
> 
> 
> Sean

what might be interesting is to make a version that works with slices of the file rather than ram. (make the current version into a template specialized on char[] and the new one on some new type?) That way only the parsed meta data needs to stay in ram. It would take a lot of games mapping stuff in and out of ram but it would be interesting to see if it could be done.