RobM> The reason we lose more performance than Moore's law gives back is because there are so many programmers (undeserving of the title "software engineers") who would rather use some huge, unoptimal software package or library than spending days, weeks or even years learning how to do it efficiently. (Market forces play a role too :-) Something like this describes Mathematica's misbegotten and hopelessly overloaded Sum facility, which grows slower with each version. It just took 9 minutes to do absolutely nothing with one of those Lambert identities I sent. Trying a trivial simplification like shift or rename the summation index takes many more minutes. Julian, Corey and I wasted most of yesterday trying to work around this, which is pretty much of a showstopper for porting my path invariance stuff to Mma. We tried hiding HoldForms everywhere, inserting undefined functions, faked summation operators,... but nothing was much good for actually manipulating Sums Just now I made a function which, if wrapped around a transformation of a Sum, reduces the time from many minutes to many seconds. But it happens inside the Sum, and doesn't help you extract summand factors which are independent of the index, e.g. Of all the insane things Mma must be trying in those 9 minutes, why not this actually useful one? Hillclimbing for performance workarounds is made difficult by Sum attempting to ameliorate the delays by caching results. Which ClearSystemCache doesn't clear! The whole design of Sum appears based on the assumption that the very last thing in the world I want from typing Sum is a sum. I would *much* rather have several screenloads of HypergeometricPFQRegularizeds, or just give up and get $Aborted. Sum even offers 6*22 strategy X method combinations with which to destroy my sum. Unfortunately, the default is Automatic, and there is no Method->None ! (And if there were, it would ruin the typesetting.) This too is neither math nor fun. --rwg Perhaps the problem is ossified project leadership.