Hi
Maybe Dave can comment this , but with the normal C++compiler and the
HEAPPOOL(ALIGN, .. option we got 5-10% performance improvements.
I would take a DUMP, to see what is going around this address.
On 18.12.2012 04:05, Phil Smith wrote:
Dave Rivers wrote:
The routine in question appears to only be 64 bytes long?
Pretty small - any chance of looking at a dump or something and seeing what is
at that address?
No, that's the "slice" size that's set in APA. I've made it bigger but it made
no apparent difference. I am trying to figure out what's at that address, and why it's
not telling me the EP name (for that matter, I'm not sure how it knows the ones it does
know).
What's weirder still about this problem is that when I started tuning, it was showing the
job as spending more than 50% of its time in CEEVGHPH, aka "XPLINK non-heap pools
get heap". Scratching my head, and knowing that the code does a lot of SHA-1 and
SHA-256 operations, I taught it to use CPACF instead (the SHA code isn't mine, and I saw
no point in grokking it, since CPACF is surely better, at 5M/second, at least on a zEC12;
this is a z10, but still). So now it's spending a LOT less time in CEEVGHPH-like 20%--but
the overall job time has only gone down about 10%! That's why I'm wondering about the
capture ratio.
Now, this is on a development system, a 2GB z/OS guest under z/VM, so I don't
know if there are small-system effects at play here, either.
As you can see, I have a lot of questions to answer. Sure wish the APA doc were
a bit more helpful.
Hints, ideas, brickbats welcome.
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
