dxml 0.1.0 released

[Jonathan M Davis]

On Saturday, February 10, 2018 16:14:41 Jacob Carlborg via Digitalmars-d-
announce wrote:
> On 2018-02-09 22:15, Jonathan M Davis wrote:
> > Currently, dxml contains only a range-based StAX / pull parser and
> > related helper functions, but the plan is to add a DOM parser as well
> > as two writers - one which is the writer equivalent of a StaX parser,
> > and one which is DOM-based. However, in theory, the StAX parser is
> > complete and quite useable as-is - though I expect that I'll be adding
> > more helper functions to make it easier to use, and if you find that
> > you're doing a particular operation with it frequently and that that
> > operation is overly verbose, please point it out so that maybe a helper
> > function can be added to improve that use case - e.g.
> This is great news! Have you run any benchmarks to see how it performs?

Kind of. I did some benchmarking to see if some code changes would improve
performance, but I haven't tried benchmarking it against any other XML
libraries. That would take a fair bit of time and effort, and IMHO, that
would be better spent finishing the library first. Also, ldc's latest
release is only up to dmd 2.077.1, and dxml needs an improvement that got
added to byCodeUnit in 2.078.0, so any benchmarking that wants to do
something like compare dxml with a C/C++ parsing library while taking the
optimizer out of the equation isn't going to work yet unless I fork
byCodeUnit for dxml until we get another release of ldc.

One result of the benchmarking that I did do allowed me to simplify the code
quite a bit though. I'd originally had it be configurable whether the parser
kept track of the line number and column of the document, just the line
number, or neither on the theory that I really wanted access to the position
in the document in error messages but that it would affect performance, so
it should be configurable. However, benchmarking showed that it had
negligible impact on performance to the point that different PositionTypes
won out depending on the file and the particular run of the program,
indicating that that extra complexity was buying me nothing. There were a
fair number of static ifs to deal with that configuration option, so as soon
as I was able to measure that they didn't matter particularly, I removed
that option from the Config and all of its associated static ifs in the
parser and was able to reduce the complexity of the code a fair bit. Testing
that bit was actually the main reason that I did any benchmarking before
releasing anything, since I wanted to avoid changing the API later if I
could.

I am going to need to spend more time benchmarking code changes at some
point here though to see if I can make the parser faster, and eventually, I
will probably benchmark it against other parsing libraries. I fully expect
that it will compare favorably given that it does almost no heap allocations
and slices everything, but there's every possibility that I did something
algorithmically internally that hurts performance more than it should - e.g.
while it tries to parse everything only once, there are a few places where
it ends up taking a second pass over a piece of text, and refactoring that
is on my todo list (though most of the other potential improvements I did
benchmark were a wash, so I may find that it doesn't matter much).

I'll probably be in more of a hurry to benchmark dxml against other parsing
libraries if my dconf talk proposal on it gets accepted, since that's the
sort of thing that should probably be in such a talk.

I haven't even taken the time yet to figure out which libraries it should be
benchmared against.

- Jonathan M Davis