Hi again,

I think that some of the points you exposed are valid and are very
interesting. However, the Rhino lexer & parser have together only about
300 lines of code, so that is not *that much* code.

However, it looks like the approach you mentioned could be valid for
other projects that could need it and have a bigger complexity.

Regards,
Carlos.

El jue, 17-06-2004 a las 14:56, Stuart Ballard escribiÃ:
> Carlos Alberto Cortez wrote:
> > Hi:
> > 
> > Currently I'm helping Cesar Lopez Nataren to port the Rhino Lexer and
> > Parser stuff, and then finish the JScript compiler implementation. Maybe
> > it would be a good idea to finish to port to C#, than trying to use them
> > with IKVM, since you would have to run ikvm on top on mono, and then run
> > rhino on top of ikvm, representing a big overhead.
> 
> If you use ikvmc, the overhead isn't that huge and could be reduced 
> further with a small amount of work (which would help other users of 
> IKVM as well).
> 
> A small amount of overhead for mapping certain method calls (not all) on 
> java.lang.Object and java.lang.String is unavoidable, as is a larger 
> amount of overhead when exceptions are used, but exceptions are slow 
> anyway and shouldn't be used in performance-critical parts of the code.
> 
> The rest of the current overhead, as far as I know, is memory overhead 
> caused by the need to have all of IKVM.GNU.Classpath.dll and all of 
> IKVM.Runtime.dll loaded even when not all of it is in use. Classpath.dll 
> could be split up by Java package so that you might only need to load 
> the java.lang equivalents and maybe java.io. IKVM.Runtime.dll could have 
> the JIT compiler split out because you don't need it when you're in 
> static mode, unless you're doing dynamic loading of classes. I believe 
> that the IKVM author plans on doing these things anyway, eventually, 
> although they won't make Mono 1.0.
> 
> It occurs to me that perhaps Rhino *does* do dynamic loading of classes 
> and so that overhead would be significant. Still, I imagine that adding 
> a CIL-generator as an alternative to the Java bytecode generator would 
> be less work than porting the entire code to C# - and you could benefit 
> from ongoing improvements to Rhino in the future. (Of course, you can 
> use System.Reflection.Emit directly from Java code to make the CIL 
> generator simpler to write)
> 
> Obviously I can't tell you what to do, and like I said, I don't have 
> time to work on this myself. I can only suggest what I think would save 
> you some work...
> 
> Stuart.
_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to