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__)
  . . .