If you're coming from a C++ background, you can think of Perl arrays as having most of the characteristics of a std::vector<SV*>, and a few of the characteristics of a std::deque<SV*>, where an SV* is a pointer to a scalar value, which may contain anything that scalars are allowed to contain.

In specific, Perl arrays provide constant time index lookup, linear time mid-array insertions or deletions, amortized constant time insertion or deletion at the beginning or end of the container, and constant time determination of size.

How that is implemented internally should be less important than the computational complexity of the operations you can perform on an array. In C++, vectors are guaranteed to have contiguous memory, and deque containers are not guaranteed to inhabit contiguous memory. In C++, this implementation detail leaks out of the internals into the language abstractions, in that you can copy a block of memory from an old fashioned C array to a vector of adequate size, and have an expectation that it will work. C++ also lets you do pointer arithmetic with vectors, but not with deques. But forward, reverse, and random access iterators exist for both classes to minimize the need for pointer arithmetic. Most of the time a C++ programmer is going to be satisfied just knowing the computational complexity of the various operations that one can perform on a given container class.

Internally Perl's arrays do inhabit contiguous memory, but unlike C++, that implementation detail never leaks outside of the guts layter, into the abstraction of the Perl language itself. You would have to dive into XS programming to care, and even then, you mostly don't need to worry about it.

As for memory usage, take whatever amount of memory you expect to be using, double it, and then multiply that by ten, and you won't underestimate by too much._{(Attribution needed)} ;) Perl's array elements consist of pointers to scalars, which internally are structures with many sub-components.