On 1/04/2016 10:59 PM, Ed Jaffe wrote:
On 3/31/2016 7:47 PM, Andrew Rowley wrote:
Call me a masochist, but I'm comparing Java batch to assembler. My
target is to get the Java CPU less JVM startup overhead down to the
same as assembler for the same report. I may not get there, but I
will hopefully get close.
I feel your pain! ;) Tired of double standards, our mandate is for
Java Web App performance to rival that of traditional 3270. And though
we haven't been able to reach parity, nor are we likely to, we see
<.2sec average wall-clock response time in (E)JES Web -- which I
consider to be _very_ acceptable, especially given the depth of the
calling stack: browser -> javascript -> jquery -> ajax -> TCP/IP ->
tomcat -> (E)JES Web java web service -> (E)JES java API -> C++ JNI ->
(E)JES API written in HLASM -> (E)JES base code written in HLASM.
That's fast! How are you measuring that, browser javascript toolkits? Is
there a noticeable difference using different browsers, Chrome, Firefox,
Safari etc?
We started this on a z10. Then we upgraded to a zBC12 and more
recently to a z13s. We have seen _tremendous_ Java performance
improvements (much more than other work) with each new Java release
and hardware generation. (Of course, Java started out so slow, it had
no place to go but up! LOL) Still, this says a lot about IBM's
commitment in this area, both in terms of hardware design and compiler
optimization technologies.
And, now that COBOL 5 uses the same code optimization technology used
by Java, those performance benefits are starting to permeate other
areas as well...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
