This is correct. Here is a Lisp function that allocates N cons cells:

    $ sbcl
    This is SBCL 1.0.57.0.debian, an implementation of ANSI Common Lisp.
    ...
    * (defun nlist (n) (loop for i from 1 to n collect i))
    NLIST
    * (nlist 5)
    (1 2 3 4 5)
    * (compile 'nlist)
    NLIST
    NIL
    NIL

Let’s see how long it takes to allocate two million 500-item lists, totaling a billion allocations:

    * (time (dotimes (i 2000000) (nlist 500)))
    Evaluation took:
      6.477 seconds of real time
      6.460403 seconds of total run time (6.416401 user, 0.044002 system)
      [ Run times consist of 0.384 seconds GC time, and 6.077 seconds non-GC time. ]
      99.74% CPU
      18,093,926,186 processor cycles
      16,032,024,704 bytes consed

    NIL

That’s 6.5 nanoseconds and 18 “processor cycles” (does SBCL use performance counters for this or is it guessing?) per 16-byte allocation. That’s about 150 million allocations per second, including the time to initialize those allocations and increment the loop counter and whatnot, and also (contra chrisseaton) the time to deallocate those lists. If we increase the list length and proportionally decrease the iteration count, this performance remains consistent up to 50,000-item lists, but at 2000 iterations of half a million items, it starts taking 10 seconds instead, presumably because the lists no longer fit into the generational garbage collector’s nursery, so it has to spend a third of its time in the garbage collector.

The above is running on one core of a “Intel(R) Core(TM) i7-3840QM CPU @ 2.80GHz”, so if 18 processor cycles is not correct, it’s a damned good guess. Also, this CPU is from 02012, nine years ago.

What does this look like at the machine level? NLIST disassembles to 87 lines of assembly, so I’ll spare you most of it and excerpt only one of the allocations:

    * (disassemble 'nlist)
    ; disassembly for NLIST
    ; 029ECE7D:       488B4DF8         MOV RCX, [RBP-8]           ; no-arg-parsing entry point
    ...
    ;      EF9:       4D8B5C2418       MOV R11, [R12+24]
    ;      EFE:       498D4B10         LEA RCX, [R11+16]
    ;      F02:       49394C2420       CMP [R12+32], RCX
    ;      F07:       0F8696000000     JBE L9
    ;      F0D:       49894C2418       MOV [R12+24], RCX
    ;      F12:       498D4B07         LEA RCX, [R11+7]
    ;      F16: L4:   49316C2440       XOR [R12+64], RBP
    ...
    ;      FA3: L9:   6A10             PUSH 16
    ;      FA5:       4C8D1C2570724200 LEA R11, [#x427270]        ; alloc_tramp
    ;      FAD:       41FFD3           CALL R11
    ;      FB0:       59               POP RCX
    ;      FB1:       488D4907         LEA RCX, [RCX+7]
    ;      FB5:       E95CFFFFFF       JMP L4

As best I’ve been able to figure out, the nursery allocation pointer is stored in memory at [R12+24], the pointer to the freshly allocated dotted pair comes out of this sequence (at L4) in RCX, and the pointer to the end of the nursery is stored in memory at [R12+32]. So the actual allocation is, in the normal case, the six instructions from 029ECEF9 up to 029ECF16. If the nursery is full, it takes the jump to L9 to invoke a minor garbage collection. It may help to know that on amd64 SBCL represents dotted-pair pointers with, essentially, a pointer to their 7th byte, which is what all that RCX+7 nonsense is about.

In games it's common to use a similar pointer-bumping allocator for many allocations and then deallocate the whole heap at the end of the frame (by resetting the allocation pointer)—in that case, you don't even need the check against the heap limit, you just need to make sure you never come close to overflowing it. The Packrat-parsing backend of the project I'm working on at the moment, http://gitlab.special-circumstanc.es/hammer/hammer, does the same thing, but the arena is per-parse rather than per-frame, and it may be divided into multiple separately malloced blocks. Also, unlike SBCL, Hammer is in C, so it can't inline the calls to `h_arena_alloc`; they typically have to pay two instructions of argument setup, one instruction of function call, one instruction of return value handling, another instruction of PLT shared library overhead, and then the actual function is 26 instructions in the usual case.

The moral of the story is that the performance of fundamental operations depends strongly on the tradeoffs you make in your system design.

It's still true, though, that pointer-heavy data structures are terrible for cache locality (an L3 cache miss costs about 100 ns, as much as 15 allocations on one core, but typically the L3 cache is shared across all cores or at least all the cores on one socket), and that HPC consists mostly of large numerical arrays and not pointer chasing. Consequently, the software stacks used in HPC aren't optimized to make allocation cheap; they're optimized for other operations, and so they allow allocation to be expensive. I've explored this fascinating issue in somewhat more detail in http://canonical.org/~kragen/memory-models.

(It's a deeply damning commentary on the climate of boastful intellectual vacuity this site fosters that comments like this get downvoted for showing empirical evidence and comparing results from a wide variety of contexts, while confident but totally clueless comments about how an allocation necessarily involves acquiring locks and whatnot get voted up to the top. I guess they take less time to make!)