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