> We have an application written in C that has begun to run long. The > application support team feels some LE storage tuning could help (it > improved their CICS response time when done last year). We're also going > to > look at XPLINK and I was asked how much improvement that could expect.
ISTR that XPLINK is either unusable in CICS, or has some significant gotchas in that environment. But I'm not remotely interested in CICS, so I have never paid any attention to the details. A quick scan of the LE books would yield the answer either way. > They and I know there's no way to give a true estimate considering all the > other variables but perhaps those that have done this could come forward > with their experiences. For your applications program what benefits did > you see comparing before and after using XPLINK. "It depends". The entire rationale for XPLINK is that applications written in "languages like C++" (in other words, just C++) tend to be composed of lots of small functions of a handful of lines each. In those cases, the execution path length of each small function is small and the costs of standard OS linkage (and parameter passing) become the dominant factors. XPLINK plays a lot of register games to avoid the full STM/LM sequence for saving and restoring the caller's registers and also avoid (as much as possible on a case by case basis) fetching parameter values into registers. It also uses a downward growing stack with a guard page to avoid the two or three instructions that would otherwise have been used to check for the end of the current stack (BFD) Code that is compiled for XPLINK also avoids the traditional "branch around the eyecatcher" code sequence at entry to each function (also, probably BFD) What does it buy you? Well, if your application really does look like a typical C++ application, then you can save quite a lot of CPU time by (re-)compiling for XPLINK. It really does work and the tinier the called functions are, then the bigger the improvement you will see. However, if your application ISN'T like that, then at best you're going to do about the same as you would have done without XPLINK. More often you're going to do worse. The really damaging XPLINK usage case is for functions (no matter what their implementation language) that make lots of external calls out of the XPLINK environment into "normal" code. LE has to swap backwards and forwards between the XPLINK and non-XPLINK environments at the call boundary. If your application code does that, or if it calls things that do that (e.g. if it has ILC calls, or if it is just a mixture of XPLINK and not) then it probably is going to suck. The thing I personally dislike is that debugging an XPLINK problem is a royal PITA. For that reason I would avoid it unless the performance gain was really compelling. For something that doesn't run thousands of times a day I don't believe you would ever find it worthwhile either way. If you have the source, you can probably recompile the code and try it out. That's going to be the best estimator. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
