[jdom-interest] Still more Verification

[Oliver Imbusch]

>>>>> "erh" == Elliotte Rusty Harold <elharo at metalab.unc.edu> writes:
>>>>> "jh" == Jason Hunter <jhunter at collab.net> writes:
>>>>> "oi" == Oliver Imbusch <flabes at livis.de> writes:

    erh> May I ask why you turned off the verification code?

I have subclassed Element:

    public class MyElement
        extends Element {

        public MyElement () {
            // would have used
            //   super ("myElement");
            // but that performs expensive Verifier.checkElementName(name)
            // test; use no-arg Element constructor to bypass that test
            // and assign protected fields manually
            super ();
            this.name = "myElement";
            namespace = Namespace.NO_NAMESPACE;
            // that's the default
            //    isRootElement = false;
        }
    }

The name is always "myElement", it's correct, and I don't want it to
be tested over and over again.

    erh> What was the program?

An editor for specially formed documents (I can't go into the very
details here, sorry). The documents exist in a compact external
representation (more or less human-radable XML files) and a talkative
internal representation (JDOM) suitable to implement the
editor. Roughly spoken, in the external form I have strings as
strings, internally I have sentences with nested words which in turn
have nested character tags (that really makes sence in my application,
believe me). Cursor movements in the editor correspond to navigation
in the JDOM tree, character/word deletion/insertion and the like
correspond to creation and removal of JDOM nodes and sub-trees. Import
and export means expansion and collapsing of nodes (it's not all that
simple, but I think you get the point).

    erh> What performance measurements showed you that this was the
    erh> bottleneck in your code? How much speed did you gain by
    erh> disabling the verification?

I don't have the hprof analysis at hand, but I recall that ~15% was
spent in useless checking. You mention ~20% yourself in another
posting.

    jh> But how would one differentiate between the two?

    oi> public void setValue (String value, boolean check) {
    oi>     if (check) {
    oi> 	String reason = Verifier.checkCharacterData (value);
    oi> 	if (reason != null) {
    oi> 	    throw new IllegalDataException (value, reason);
    oi> 	}
    oi>     }
    oi>     this.value = value;
    oi> }

    erh> I really don't like this option. It lets programmers who
    erh> don't understand what they're doing sacrifice program
    erh> correctness in the name of the false god performance.

That's why I turned checking on in my convenience (read: backward
compatibility and correctness enforcing) wrapper:

    oi> public void setValue (String value) {
    oi>     setValue (value, true);
    oi> }

Would be OK to make the setValue(String,boolean) protected, just like
Element() is.

    erh> In my experience, programmers are way too quick to make
    erh> pointless optimizations and way too slow to make sure their
    erh> code actually does what it's supposed to do.

I too like correct programs, but performance is not a bad thing in
general. JDOM exactly reflects my data model, and it gives me XML
im-/export for free, so I want to use it. But I also want to have a
responsive user interface and thus I need the room for
optimization. Tags and attributes I generate programmatically are
correct (modulo bugs, of course), they don't depend on user input at
runtime: there's no need for a check.

All in all: I vote for restrictive (checking) public methods, and
performance-optimzed protected methods for the "I know what I'm doing"
programmer.

-Oliver