Re: [Fenfire-dev] Yet another libvob API: LWJGL

[Benja Fallenstein]

On 1/17/06, Tuukka Hastrup <address@hidden> wrote:
> > Nor do I think that string parsing could be made fast enough for this,
> > remembering that I've been told parsing is the slowest part in a
> > compiler. :-)
>
> I have to make sure you're not just joking :-)

Nope.

It's not a particularly easy thing to google for, but I tried with
'compiler parsing "most expensive"' and two of the first ten hits were
statements to basically the same effect. Except that the first one
pulls it apart a bit more and says that not parsing, but lexical
analysis, is the most expensive step.

http://64.233.183.104/search?q=cache:wgFuog3QIKYJ:www.cl.cam.ac.uk/Teaching/2001/CompConstr/CompConstr0102aux.pdf+compiler+parsing+%22most+expensive%22&hl=en
http://www.eros-os.org/pipermail/e-lang/1999-June/002668.html

I admit I have not done any real background check on the people who
said this. The first appears to be from a course and as for the
second, I've heard of e-lang before and the people on the mailing list
seem knowledgeable, but who knows. :-)

CallGL may be much easier to parse than a real programming language, though.

> I was on the basis that
> tokenization is orders of magnitude faster than JNI calls, which of course
> may be totally wrong.

I wouldn't know either :-)

> You're right, if we are to implement Libvob/GL in Java, it could probably
> be pretty independent from the native wrapper. But if this can't be made
> fast enough, all the work has been for nothing, right?

Yeah, but we won't know if it's fast enough before we try it, anyway.
My point was that we can try with the wrapper and if it's not fast
enough, we can still try with the other system, without having to
throw away the code we've done so far.

> Now it might be a gain in itself to have as much of the code in Java and
> as little in C++ as possible, but that's not how I understood Matti and
> the situation. As long as we need to release some native code someone has
> to port it, maintain it, compile it. Would it be a significant change to
> have less native code?

More people might feel able to work on the Java version of Libvob/GL
than the C++ version (hint: me). But using an off-the-shelf wrapper
would be much preferable. Another reason to try that first. :-)

- Benja