jython-users

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[<Mat...@i2...>]

Someone answered this question for me a few days ago.  Check the 
jython-users archive for details.
You use interp.set("name", objectValue) to pass to jython from java, and I 
guess the easiest way from jython back to java would be to call a setter 
on some object you passed in using interp.set()

Matt






rohit seth <ro2...@ya...>
Sent by: jyt...@li...
10/03/01 08:54 AM

 
        To:     jyt...@li...
        cc: 
        Subject:        [Jython-users] Extending the runtime flexibility of my Java application 
using Jython


Hi,

I am planning to use Jython scripts to extend the
runtime flexibility of my Java application. Just
wanted to know if it is possible to pass and retrieve
parameters/variables from Jython file to Java File and
vice versa.

If yes, then how? Coz I have come across ways to
execute specific Jython commands from a Java file or
to execute complete Jython scripts. I dont know if
there is any possible way to pass a parameter or
variable from Jython file and retrieve it in Java
file..or the other way round.

Thanks and Regards,

Rohit


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

_______________________________________________
Jython-users mailing list
Jyt...@li...
https://lists.sourceforge.net/lists/listinfo/jython-users

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[<Mat...@i2...>]

On 10/03/2001 02:04:35 PM jython-users-admin wrote:
> 
> The PyFactory looks something like this:

Cool, thanks for the useful pattern.
> was nice.  Incidentally, the Python implementation of the
> layout engine was 599 lines, while the Java came to 941.

Heh, yeah, I wrote a GUI jython script launcher initially in jython, it 
was about 1000 lines, had to rewrite it in Java (for speed) and it was > 
2300 lines, so I feel your pain =)

Matt

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[Carlos Q. <car...@we...>]

On Thursday 04 October 2001 00:23, Mat...@i2... wrote:

> Heh, yeah, I wrote a GUI jython script launcher initially in jython, it
> was about 1000 lines, had to rewrite it in Java (for speed) and it was >
> 2300 lines, so I feel your pain =)

Hi.
Do you have any estimation how much slower is using jython than java? I'm 
very interested to know that kind of figure

Regards

Carlos

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[Bill K. <bi...@ct...>]

From: "Carlos Quiroz" <car...@we...>
>
> On Thursday 04 October 2001 00:23, Mat...@i2... wrote:
> 
> > Heh, yeah, I wrote a GUI jython script launcher initially in jython, it
> > was about 1000 lines, had to rewrite it in Java (for speed) and it was >
> > 2300 lines, so I feel your pain =)
> 
> Hi.
> Do you have any estimation how much slower is using jython than java? I'm 
> very interested to know that kind of figure

I have extensive timing and profiling numbers for our jython html
parser and layout engine, and a rewrite of the layout engine in
java.  Well, 'extensive' in the sense that I accumulated a lot of
them in trying to tweak the jython code in the hopes of not having
to rewrite it. :)

The parser, interestingly perhaps, hasn't needed to be rewritten
in Java.  The parser, however, is very simple, relying on the 
lexer to do most of the work - and the lexer is just a big
regexp - and so in that sense we can say the lexer is 'written
in java' (in terms of the performance of the regexp engine, I
mean.  Certainly no-one in their right mind would write a lexer
>in java< when they could do it in a couple lines of regexp. ;-)

Okay.  So there's a point I'm trying to get to about the ratio
of jython-to-java, or rather, the percentage or degree to 
which a bunch of jython code relies heavily on calls to Java
classes to do much of its work - sort of a 'glue' or scripting
for the Java components, to put them together and get them to
do things; vs. jython code implementing an algorithm strictly
in pure jython.  I think our layout engine falls squarely in
the latter category, while our parser falls to a degree toward
the former; . . . well anyway, here are some numbers :)

The test data for these was a simple html document of 1364 
words (9893 characters) with a couple dozen tags strewn 
throughout, and an inline image contained in a simple table.

The jython implementation:

parse x 100: 3.5049999952316284 secs (0.03504999995231629/per)

layout x 10: 3.8459999561309814 secs (0.38459999561309816/per)

So layout was accomplished in about 2/5ths of a second.  But,
this is timed on a 1.3GHz athlon system, and our product's
minimum requirements specify a Pentium 166Mhz (or similar
speed Macintosh.)  And unfortunately, the _three seconds_
the layout might be expected to take on such a machine (and
indeed did) were a bit more that it seemed reasonable to 
ask users to tolerate. =)

Anyway here's the java reimplementation (port really) of
the layout engine (again on the GHz athlon)

layout x 1000: 8.332000017166138 secs (0.008332000017166137/per)

Zoom!  Not quite two orders of magnitude but, just about
one-and-a-half . . . 

But, again, what we're doing in the layout engine - 'pure'
jython, no Java methods called at all, really, 'cept, well
okay stringWidth() from FontMetrics, not much else - is
about as biased an example toward the poor-performance 
end of the spectrum as one can get.  We're quite happy
with the performance of the rest of our jython modules,
including the parser - and the ones that do things like
glue swing components together - I mean, speed just hasn't
been a problem for those kinds of modules.

So I didn't want to sound in any of this like I'm down on
jython or anything.  I love it actually, it's the best
alternative to Java going right now !   O:-)

That runs on the JVM I mean.  <g>

Okay.  Hope this helps,

Regards,

Bill

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[Carlos Q. <car...@we...>]

On Thursday 04 October 2001 11:42, Bill Kelly wrote:
Thanks Bill for your detailed explanation.

> Okay.  So there's a point I'm trying to get to about the ratio
> of jython-to-java, or rather, the percentage or degree to
> which a bunch of jython code relies heavily on calls to Java
> classes to do much of its work - sort of a 'glue' or scripting
> for the Java components, to put them together and get them to
> do things; vs. jython code implementing an algorithm strictly
> in pure jython.  I think our layout engine falls squarely in
> the latter category, while our parser falls to a degree toward
> the former; . . . well anyway, here are some numbers :)

This is funny, Java is becoming the equivalent to native here ;-)

> Anyway here's the java reimplementation (port really) of
> the layout engine (again on the GHz athlon)
>
> layout x 1000: 8.332000017166138 secs (0.008332000017166137/per)
>
> Zoom!  Not quite two orders of magnitude but, just about
> one-and-a-half . . .
>
> But, again, what we're doing in the layout engine - 'pure'
> jython, no Java methods called at all, really, 'cept, well
> okay stringWidth() from FontMetrics, not much else - is
> about as biased an example toward the poor-performance
> end of the spectrum as one can get.  We're quite happy
> with the performance of the rest of our jython modules,
> including the parser - and the ones that do things like
> glue swing components together - I mean, speed just hasn't
> been a problem for those kinds of modules.

Could you somehow isolate some hotspot there? It could be interesting to 
profile it with some tool (OptimizeIt comes to my mind) which can show where 
most of the time is being spent. Maybe it is possible to either optimize your 
code, or even better, optimize jython. In many cases some minor fixes are 
enough

> So I didn't want to sound in any of this like I'm down on
> jython or anything.  I love it actually, it's the best
> alternative to Java going right now !   O:-)

You bet!!!

Re: [Jython-users] Extending the runtime flexibility of my Java application using Jython

[Bill K. <bi...@ct...>]

From: "Carlos Quiroz" <car...@we...>

> > Okay.  So there's a point I'm trying to get to about the ratio
> > of jython-to-java, or rather, the percentage or degree to
> > which a bunch of jython code relies heavily on calls to Java
> > classes to do much of its work - sort of a 'glue' or scripting
> > for the Java components, to put them together and get them to
> > do things; vs. jython code implementing an algorithm strictly
> > in pure jython.  I think our layout engine falls squarely in
> > the latter category, while our parser falls to a degree toward
> > the former; . . . well anyway, here are some numbers :)
> 
> This is funny, Java is becoming the equivalent to native here ;-)

Yeah, in fact I've been waging a little 'campaign' at work, referring
to java as 'assembler' to try to make the point that there are 
higher level languages we can be programming in.  And, yeah, if you
need the speed (after profiling [jython code]) ya can always drop to
assembler if you really have to . ..   ;-)

> > Anyway here's the java reimplementation (port really) of
> > the layout engine (again on the GHz athlon)
> >
> > layout x 1000: 8.332000017166138 secs (0.008332000017166137/per)
> >
> > Zoom!  Not quite two orders of magnitude but, just about
> > one-and-a-half . . .
> >
[...]
> Could you somehow isolate some hotspot there? It could be interesting to 
> profile it with some tool (OptimizeIt comes to my mind) which can show where 
> most of the time is being spent. Maybe it is possible to either optimize your 
> code, or even better, optimize jython. In many cases some minor fixes are 
> enough

I was using the built-in Python/jython profiler which was pretty nice.
I didn't ever profile at the Java level though to see where the time
was being spent in jython itself.  But looking through the source code
I was seeing that jython goes through an inordinate amount of trouble
to make Java objects accessible from jython very seamlessly.  I mean,
the fact that my unit tests didn't change at all, most of them, despite
having rewritten the layout engine in Java surprised me quite a bit and
was very nice - as the jython code had been using lists, dictionaries,
etc. and the Java version is using java.util.Vector, java.util.Hashtable,
etc.  (I did have to change has_key() to containsKey() :-)

Anyway in looking at the jython source I did get a sense that there is
significant overhead in the machinations it goes through to try to
convert intelligently (or broker, as it were) between Java objects
and Jython objects.  But again, I didn't profile it.  And, of course,
its intelligent conversion & wrapping of Java objects is part of what
makes Jython so powerful and easy to use I think, so I'm not 
complaining or suggesting it should be done any differently.

Regards,

Bill

P.S. This is what the Python profiler output looked like (excerpt)

  149495 function calls (149305 primitive calls) in 15.169 CPU seconds

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.194    0.194   15.169   15.169 profile:0(testLayoutSpeed())
        1    0.011    0.011   14.975   14.975 htmllayoutProf.py:21(testLayoutSpeed)
        1    0.000    0.000   14.975   14.975 <string>:0(?)
       10    0.002    0.000   14.673    1.467 htmllayout.py:20(layout)
   200/10    0.053    0.000   14.299    1.430 htmllayout.py:748(produce)
      530    3.035    0.006   13.445    0.025 htmllayout.py:771(produce)
    13720    2.427    0.000    5.118    0.000 htmllayout.py:527(__init__)
    26770    1.563    0.000    3.725    0.000 htmllayout.py:60(accept)
    26770    1.520    0.000    2.131    0.000 htmllayout.py:195(accept)
       20    0.002    0.000    2.034    0.102 htmllayout.py:878(produce)
    13720    1.150    0.000    1.150    0.000 htmllayout.py:722(stringWidth)
      530    0.968    0.002    0.968    0.002 sre.py:191(_split)
    13970    0.883    0.000    0.883    0.000 htmllayout.py:703(getFontHeight)
      800    0.187    0.000    0.816    0.001 htmllayout.py:669(__init__)
    14060    0.694    0.000    0.694    0.000 htmllayout.py:84(__init__)
      800    0.629    0.001    0.629    0.001 htmllayout.py:685(_LayoutStyle__initFontMetrics)
    26770    0.611    0.000    0.611    0.000 htmllayout.py:248(accept)
       10    0.004    0.000    0.573    0.057 htmllayout.py:865(produce)
      250    0.018    0.000    0.551    0.002 htmllayout.py:63(newRow)
      110    0.081    0.001    0.544    0.005 htmllayout.py:791(produce)
      260    0.044    0.000    0.542    0.002 htmllayout.py:45(curStyle)
      250    0.011    0.000    0.529    0.002 htmllayout.py:201(newRow)
      250    0.093    0.000    0.518    0.002 htmllayout.py:287(newRow)
      190    0.010    0.000    0.410    0.002 htmllayout.py:803(produce)
       10    0.002    0.000    0.362    0.036 htmllayout.py:29(initLayoutState)
        1    0.101    0.101    0.291    0.291 htmlparse.py:60(parse)
        1    0.000    0.000    0.291    0.291 htmllayout.py:14(__init__)
  . . .