XOM API for Processing XML with Java

[cowwoc <cowwoc AT bbs.darktech.org>]

	By the way, this also causes major StackOverflowErrors for Proguard. 
Increasing the stack-size allows it to proceed further but then it 
crashes with:

IllegalArgumentException: Branch instruction can't be widened (goto_w+56833)

	I've reported the problem to the author but this is yet another example 
of the headache caused by this code: 
http://sourceforge.net/forum/forum.php?thread_id=2120087&forum_id=182456

	What kind of performance impact would you see by splitting this code 
across two methods? Secondly, looking at UnicodeUtil.getCombiningClass() 
I see quite a bit of wasted instructions. For example,

        if (c == 0x0028) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
        if (c == 0x0029) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
        if (c == 0x002A) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
        if (c == 0x002B) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
        if (c == 0x002C) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;
        if (c == 0x002D) return CANONICAL_COMBINING_CLASS_NOT_REORDERED;

could be replaced by

        if (c >= 0x0028 && c <= 0x002D) return 
CANONICAL_COMBINING_CLASS_NOT_REORDERED;

	There are literally hundreds of such lines that could be folded down 
into a single line of code. In other words, this bug is fixable. If I 
manually optimize this code would you merge my changes into future releases?

Thank you,
Gili

cowwoc wrote:
>     Normally I would agree with you, but seeing as the reference 
> implementation JDK has this problem and they do not plan on fixing it I 
> think you should seriously reconsider: 
> http://bugs.sun.com/view_bug.do?bug_id=6453531
>
>     To be clear, not only are you risking compiler crashes here, but 
> also a severe runtime performance drop. Unless you know of a way to get 
> this fixed through OpenJDK I suggest you make sure none of your own code 
> surpasses the 8000 byte limit.
>
> Gili
>
> Elliotte Harold wrote:
> > cowwoc wrote:
> >
> > >     There should definitely be a better way of mapping characters 
> > > than dumping a whole slew of if statements into a method. Have you 
> > > tried asking on the Java discussion forums?
> >
> > There are such ways and I use them, but the goal is maximum efficiency 
> > at runtime, not working around compiler bugs. This is a real hot spot 
> > in XOM and some serious effort has gone into optimizing every last 
> > millisecond out of this. Check out my chapter in Beautiful Code for 
> > the details sometime.
> >
> > The simple fact is that the most efficient way is table lookup (O(1)) 
> > based on carefully constructed switch statements with no holes. If 
> > it's legal code and a compiler can't handle it, then get a better 
> > compiler. I'm not going to slow XOM down to work around compiler bugs.