Modern Alembic is read by mmap and loads only the file pages the renderer requests. Assuming the renderer doesn't overrequest samples, the I/O overhead is quite efficient. And yes, the layout of your geometry in your Alembic can have a
significant impact on rendering I/O.
The talk covers how a production went sideways because of Alembic's mmap and how the files were written out. If I recall correctly, Alembic doesn't specify an madvise, so you get MADV_NORMAL by default which will load 32 pages worth of data (128 KB) around the requested data read. This is normally fine if all your sample data for a frame was written out together, as is usually the case in Houdini where it saves frame by frame. But when using tools like the abcstitcher which writes out data object by object, instead of frame by frame, you can run into cases where to read one frame's worth of data with the default mmap MADV_NORMAL will cause your entire file to be read in. In one production, the required data for a frame should have been around 700MB, but the I/O overhead was about 11GB due to the overreading caused by mmap. Our fix for this was to add an env var, that would set an madvise of MADV_RANDOM, which only reads the specific pages requested.