commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [jxpath] Java code from JXpath expression
Date Wed, 08 Mar 2006 04:07:46 GMT

On 08.03.2006, at 14:31, Dmitri Plotnikov wrote:

> Hi,
>
> I have thought about using this type of compilation to byte code.  
> Unfortunately, I got mired in the tremendous _potential_ complexity  
> of data models that JXPath works with.   Imagine that you have an  
> expression that needs to traverse a path through a graph with the  
> root in JavaBean, followed by a property that is declared to be of  
> type "Object". What type is it really? We don't know 'till the  
> runtime, at which point we discover that it really is a Map that  
> contains a List that contains an object handled by a custom  
> NodeFactory.  That NodeFactory takes us to a Container that  
> resolves into a DOM object. And then we do a few steps through the  
> DOM tree.  That last step kind-of resembles XPath :-)
>
> I just could not figure out how to translate all of this complexity  
> to Java or byte code reliably.

Well if you can generate source code that compiled really improves  
performance then surely you can also directly generate the byte code  
instead ...no idea how the generated code needs to look like though.  
TBH I don't have much of a clue how jxpath does its magic ;)

>>> IMHO that's an ugly approach ...rather I would try to improve  
>>> jxpath.
>>
>> You are certainly entitled to your opinion :-)

Thanks ;)

>> Maybe because my sense of aesthetics is skewed I fail to see the  
>> ugliness you speak of, but I'm more than willing to be educated.

It's just unnecessary overhead. Besides I am not a big fan of source  
code generation in general (mostly because it's a one-way street) You  
should ask yourself "who will ever look at the code"? ...if no one  
does it does not make much sense to pipe it through an compiler IMO.

>>> When caching reflection you can get the same speed as native (at  
>>> least
>>> in some areas).
>>
>> Could you please elaborate on this...  I don't understand what  
>> exactly should be cached.
>> The result of the evaluation? Maybe I'm missing something but if  
>> the Context object is always changing is there a point in "caching  
>> reflection"?

Obtaining the Method and Field objects is expensive.
Once you have them - keep them! ...and you will save quite some cpu  
cycles. If jxpath already does that I am not sure the source code  
generation detour will give you the speed improvement you are looking  
for.

>>  Another option would be to generate byte code internally
>>> (like XSLTC does)
>>
>> Ok... that sure is a possibility,  any pointers on how/where to  
>> start?

First you need to find out what the code needs to look like! Compare  
and see whether it really makes a huge difference - or is possible at  
all.

Then have a look at BCEL, ASM and of course XSLTC

>> Although I'm a heavy user of JXPath I'm ashamed to admit that I  
>> barely know it's inner workings

Same here ... Dmitri just did a too good of a job :)

>>  Going through the source code stage just to avoid
>>> reflection speed sounds like the wrong approach to me.
>>
>> It's just a possibility, what I really want is not to use reflection.

...if that is really possible at all.

cheers
--
Torsten
Mime
View raw message