user31105: I noticed there are quite some libraries for the 23LC1024 SRAM 1 Mbit memory:

SpiRam Extended library
SpiRam library
Direct SPI ?

I tried 1 and 3 so far. What I noticed was that to read 1 byte took around 18 us for the 3th solution and around 25 us for the first library. However, the first has possibilities to read multiple bytes and that considerably speeds up the time.
Also there are other libraries like MQTT and possibly I missed some.
However, in all cases I would expect speeds around just a few us. Since I maybe need to read 100 of different small groups of bytes preferably within 10 us (and process them), it might get problematic in worst case scenarios.
Does anybody know where the speed differences come from or if there are ways to increase the speed or which library is fast? 

user13432: This was an excellent challenge for an SPI bus manager and device driver support library I have been working on. Below are some performance results for the SRAM (23LC1024) device driver (Arduino Uno @ 16 MHz, SPI @ 8 MHz) read/write us per byte, kbytes/s, in benchmark.
write: 9.875 + N*1.4275 us, max. 700 kbyte/s
read: 9.875 + N*1.5 us, max. 670 kbyte/s
where N is the number of bytes transfered

The protocol overhead (9.875 us) is 1) slave select pin handling, and 2) command byte and 24-bit address (four bytes header in total). 
Cheers!
Update [2017-09-25]
@MichelKeijzers I recently had time to work on an abstraction of external storage and refactor a number of device drivers to support the new interface. The abstraction includes memory block allocation, caching, handling of large vectors, and streams on external storage. Please see https://github.com/mikaelpatel/Arduino-Storage for more details; benchmarks, example sketches, etc.

user4143: SPI RAM has two modes of operation: single byte and "page mode".
In single-byte mode you first send the read or write command followed by the (typically 3-byte) address and then read a byte. That's 5 bytes per transaction, or 40 SPI clock cycles. At the maximum of 8MHz (SPI_CLOCK_DIV2 on a 16MHz MCU) that would be at absolute best (1/8000000*40) 5µS per byte read or written. That's not including the time taken to toggle the CS pin and perform the other software-level parts of controlling the SPI peripheral.
In page mode it is possible to send one start address and then read or write sequential data from that address upwards. Ideal if you need to read a larger number of bytes that are sequentially in memory. For instance, to read 100 bytes sequentially it would take 104 SPI bytes - one for the read/write command, three for the start address, and 100 for the data. That is 832 SPI clocks, or at 8MHz, 104µS. 
As you can see, reading 100 bytes within 10µS is not possible on an Arduino with SPI SRAM. There just isn't enough speed. Even 100 sequential bytes. 100 "small groups of bytes" just ain't gonna happen. 
There are other technologies that are faster which may be more suited to your use, but they require different peripherals in the chip (namely SQI), and the chips with that in tend to be more powerful and have more RAM anyway, so your 1Mb of external SRAM would be redundant.

31105: <p>I noticed there are quite some libraries for the 23LC1024 SRAM 1 Mbit memory:</p>

<ol>
<li><a href="https://thearduinoandme.wordpress.com/libraries/spiram_extended/" rel="nofollow noreferrer">SpiRam Extended library</a></li>
<li><a href="http://forum.arduino.cc/index.php/topic,182918.0.html" rel="nofollow noreferrer">SpiRam library</a></li>
<li><a href="https://ucexperiment.wordpress.com/2013/02/26/more-memory-arduino-and-23lc1024/" rel="nofollow noreferrer">Direct SPI ?</a></li>
</ol>

<p>I tried 1 and 3 so far. What I noticed was that to read 1 byte took around 18 us for the 3th solution and around 25 us for the first library. However, the first has possibilities to read multiple bytes and that considerably speeds up the time.</p>

<p>Also there are other libraries like MQTT and possibly I missed some.</p>

<p>However, in all cases I would expect speeds around just a few us. Since I maybe need to read 100 of different small groups of bytes preferably within 10 us (and process them), it might get problematic in worst case scenarios.</p>

<p>Does anybody know where the speed differences come from or if there are ways to increase the speed or which library is fast? </p>
 13432: <p>This was an excellent challenge for an <a href="https://github.com/mikaelpatel/Arduino-SPI" rel="nofollow noreferrer">SPI</a> bus manager and device driver support library I have been working on. Below are some performance results for the <a href="https://github.com/mikaelpatel/Arduino-Storage/blob/master/src/Driver/MC23LC1024.h" rel="nofollow noreferrer">SRAM</a> (23LC1024) device driver (Arduino Uno @ 16 MHz, SPI @ 8 MHz) read/write us per byte, kbytes/s, in <a href="https://github.com/mikaelpatel/Arduino-Storage#23lc1024-spi-sram-8-mhz" rel="nofollow noreferrer">benchmark</a>.</p>

<pre><code>write: 9.875 + N*1.4275 us, max. 700 kbyte/s
read: 9.875 + N*1.5 us, max. 670 kbyte/s
where N is the number of bytes transfered
</code></pre>

<p>The protocol overhead (9.875 us) is 1) slave select pin handling, and 2) command byte and 24-bit address (four bytes header in total). </p>

<p>Cheers!</p>

<p>Update [2017-09-25]</p>

<p>@MichelKeijzers I recently had time to work on an abstraction of external storage and refactor a number of device drivers to support the new interface. The abstraction includes memory <a href="https://github.com/mikaelpatel/Arduino-Storage/blob/master/examples/Block/Block.ino" rel="nofollow noreferrer">block</a> allocation, <a href="https://github.com/mikaelpatel/Arduino-Storage/blob/master/examples/Cache/Cache.ino" rel="nofollow noreferrer">caching</a>, handling of large <a href="https://github.com/mikaelpatel/Arduino-Storage/blob/master/examples/Vector/Vector.ino" rel="nofollow noreferrer">vectors</a>, and <a href="https://github.com/mikaelpatel/Arduino-Storage/blob/master/examples/Stream/Stream.ino" rel="nofollow noreferrer">streams</a> on external storage. Please see <a href="https://github.com/mikaelpatel/Arduino-Storage" rel="nofollow noreferrer">https://github.com/mikaelpatel/Arduino-Storage</a> for more details; benchmarks, example sketches, etc.</p>
 4143: <p>SPI RAM has two modes of operation: single byte and "page mode".</p>

<p>In single-byte mode you first send the read or write command followed by the (typically 3-byte) address and then read a byte. That's 5 bytes per transaction, or 40 SPI clock cycles. At the maximum of 8MHz (SPI_CLOCK_DIV2 on a 16MHz MCU) that would be at absolute best (1/8000000*40) 5µS per byte read or written. That's not including the time taken to toggle the CS pin and perform the other software-level parts of controlling the SPI peripheral.</p>

<p>In page mode it is possible to send one <em>start</em> address and then read or write sequential data <em>from</em> that address upwards. Ideal if you need to read a larger number of bytes that are sequentially in memory. For instance, to read 100 bytes sequentially it would take 104 SPI bytes - one for the read/write command, three for the start address, and 100 for the data. That is 832 SPI clocks, or at 8MHz, 104µS. </p>

<p>As you can see, reading 100 bytes within 10µS is not possible on an Arduino with SPI SRAM. There just isn't enough speed. Even 100 sequential bytes. 100 "small groups of bytes" just ain't gonna happen. </p>

<p>There are other technologies that are faster which may be more suited to your use, but they require different peripherals in the chip (namely SQI), and the chips with that in tend to be more powerful and have more RAM anyway, so your 1Mb of external SRAM would be redundant.</p>
