The issue with speed I have comes from the heavy numerical use I'm putting it to: strongly coupled nonlinear differential equations. What worries me is that NDSolve is 1400 pages long, written mostly in C, and relies heavily upon the compiler framework underneath, but it still takes minutes to evaluate what should in most cases take seconds. I suspect this is partly because the flexibility of the language makes it difficult to optimize during compilation, though of course it's difficult to tell from my vantage.
It would be beautiful, however, if NDSolve were implemented in the language itself. If the speed is sufficient for numerical code, then it should be sufficient to write that numerical code in the Mathematica language, and rely on compilation for a speed up. But that path hasn't been taken. While the compiler is immature, it seems that as a company it would make sense to adopt this strategy rather than relying mostly on a monolithic kernel built in C.
Circa MMA 2, Mathematica's kernel code was about 350,000 lines of C, whereas Maple had a Kernel of only about 20,000, with most of the routines written in Maple itself.
Pattern matching is wonderfully beautiful as a core concept, though.
The most interesting discussions to me are in the first link: specifically, the limitations surrounding the use of pattern matching for the type system, the limitation of limiting UpValues to a single depth, and the analysis of the 'infinite' evaluation model.
Mathematica has completely blown me away with its power; both in the environment and the programming language. I am, however, slightly disconcerted by the separation of interpreter level Mathematica code and the compiled C code that it links to. The description on the internal implementation given in http://reference.wolfram.com/mathematica/note/SomeNotesOnInt... leave me questioning whether a language with pattern matching at its core can ever be made to be fast enough. Perhaps that's not necessary -- a compiler is incorporated and it does give quite a boost, but I would like, perhaps just aesthetically, that a language just be that language all the way down.
The most useful trick I've used is writing out numbers or calculations algebraically (in my head). For instance, if you're squaring a number near some round number, say 52, one can write.
Also really helpful: you can do powers by memorizing a few precomputed logarithms, knowing extrapolation and knowing how to convert bases.
My favorite method for doing logarithms tends to be a mix between a 'guess and check' Newton's method, and Feynman's algorithm:
Consider the problem of finding the logarithm of a fractional number between 1.0 and 2.0 (the algorithm can be generalized without too much difficulty). Feynman observed that any such number can be uniquely represented as a product of numbers of the form 1 + 2^-k, where k is an integer. Testing each of these factors in a binary number representation is simply a matter of a shift and a subtraction. Once the factors are determined, the logarithm can be computed by adding together the precomputed logarithms of the factors. The algorithm fit especially well on the Connection Machine, since the small table of the logarithms of 1 + 2^-k could be shared by all the processors. The entire computation took less time than division.