How would I optimize this parser?

[T.D.Spenser]

I'll reply to several posts at once.

The code comments you quoted weren't meant as a criticism. They are mostly notes
to myself in case I want to document my learning experience with D on some
personal website no one ever visits. I'll post criticisms separately if/when I
have any. :)

When I was speaking about several constructors, I referred to stuff like this:

    public TagNode(String name){
        this.name = name;
        this.children = new ArrayList<Node>(1);
    }

    public TagNode(String name, Node... children){
        this.children = Arrays.asList(children);
        for (Node child : children) {
            child.parent = this;
        }
    }

It's allowed in Java, but I can see why this can be prohibited.

You're right about unit tests. One thing that surprised me is that unit tests are
run when the program is run. For some reason I thought they were run immediately
after the compilation with the appropriate flag.

== Quote from bearophile (bearophileHUGS at lycos.com)'s article
> If you import:
> import core.memory: GC;
> And then you disable the GC just before parsing:
> GC.disable();
> The parsing runtime on my PC becomes about one third.

Interesting. I didn't think about GC, because there aren't any objects that get
unreferenced. But, of course, garbage collector can't know about that until it
runs. (Well, unless there is a mechanism for marking objects as non-collectible
manually.)

Tangent question. Is there a way to disable GC per application thread?

> Disabling the GC when you have to build a large data structure and re-enabling
it after the creation is a normal optimization both in CPython and D.
> You may also import:
> import std.c.stdlib: exit;
> And add this last line to the main:
> exit(0);
> to kill garbage collection at the end to remove the final collection time you
weren't timing (but was there).
> Now the total running time is about 0.3 seconds instead of 1.1 seconds.
> All this means that your code is GC-bound :-) D GC is far worse than the Java one.
> I will try to optimize other things.
> Later,
> bearophile

Thanks for such informative replies. I can't quite keep up on the weekdays, but I
will experiment with the suggestions this weekend and probably post an update of
some sort.