(1) Once upon a time, a very long time ago, there may have been some implementations of Lisp-family languages which, because people didn't know much about writing compilers or memory management systems in the early 1960s, were significantly slow compared to hand-written assembler or FORTRAN. This problem got solved in the 1970s and 1980s as people learnt about compiling high-level languages and about how to manage memory efficiently.

(2) The most distinctive (but never the only) compound data structure in Lisp-family languages is the singly-linked list (which Lisp calls just 'lists'). Incompetent or poorly-taught programmers make use of lists without understanding their performance characteristics (particularly they treat them like arrays), and this can result in programs which have terrible performance characteristics: they're slow and they scale poorly. This is made worse because Lisp is an enormously safer language than, say, C. This means that incompetent programmers can make their programs work *at all* which, in C, would be a mass of memory errors.

(3) People use Lisp-family languages to solve hard problems, such as 'attempt to show that this metric in GR describes the same spacetime as this other metric'. Problems which don't *have* general solutions and whose heuristic solutions involve enormous amounts of computation, much of it speculative as the program searches for ways of simplifying expressions. These programs are 'slow' in the sense that it takes them many minutes to do what a human can spend three years getting a PhD doing (oh, and the program finds that the human made some mistakes).

The end result of this is that a myth grows up: 'Lisp is slow'. This might have been true once, although even that is doubtful: like cannibals, it turns out that the implementation you can find was never, really, slow, but always, just across the river, over the hills, there was another implementation, which was.