Yes, IronPython generates IL which the JIT will then compile when the method is invoked - so our parse/compile time is slower due to this. We've experimented w/ a fully interpreted mode (which can be enabled with -X:FastEval) where we walk the generated AST instead of compiling it, but that mode doesn't necessarily pass all the tests (and would get worse performance for long running code).
There are other issues w/ startup time as well besides this though that we need to fix (for example we load all the types in mscorlib & System before we drop you into the interpreter, which is a lot of types to be loading...). I suspect that for a small code snippet it's issues like these that are the most noticeable. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Super Spinner Sent: Wednesday, September 06, 2006 4:03 PM To: python-list@python.org Subject: Re: IronPython 1.0 - Bugs or Features? Claudio Grondi wrote: > tjreedy wrote: > > "Claudio Grondi" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > >>I also erroneously assumed, that the first problem was detected > >>during parsing ... so, by the way: how can I distinguish an error > >>raised while parsing the code and an error raised when actually running the > >>code? > > > > > > Parsing detects and reports syntax errors and maybe something else > > if you use non-ascii chars without matching coding cookie. Other > > errors are runtime. > Let's consider > print '"Data ê"' > > In CPython 2.4.2 there is in case of non-ascii character: > sys:1: DeprecationWarning: Non-ASCII character '\xea' in file > C:\IronPython-1.0-BugsOrFeatures.py on line 3, but no encoding > declared; see http://www.python.org/peps/pep-0263.html for details > "Data♀♂ Û" > > IronPython does not raise any warning and outputs: > "Data♀♂ ?" > > So it seems, that IronPython is not that close to CPython as I have it > expected. > It takes much more time to run this above simple script in IronPython > as in CPython - it feels as IronPython were extremely busy with > starting itself. > > Claudio Grondi IronPython is a .NET language, so does that mean that it invokes the JIT before running actual code? If so, then "simple short scripts" would take longer with IronPython "busy starting itself" loading .NET and invoking the JIT. This effect would be less noticable, the longer the program is. But I'm just guessing; I've not used IronPython. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
