测试手段如下：
主循环一直在做一个变量的自加(sum1++)，当然前提保证不会溢出。
用Cortex-M3内部的Systick计数，以一秒钟为限，这个sum1的数值大小，可以判断哪种方式比较快。为了严密，我们观察第一秒到第二秒之间的计数效果；而不是从第0秒到第1秒（因为使能Systick到真正开始执行sum1++可能有间隙）。在第一次进入Systick的ISR时，记录下sum1的值；第二次进入Systick的ISR时，再次记录sum1的值，两次值之差即为一秒钟间隔中sum1执行了多少次自加。由此看出哪种方式比较快。
同样的测试前提：Prefetch Buffer Enable + Flash Latenty="2" (根据Flash Programming Manual中要求的那样，当48MHz<SYSCLK<=72MHz时，对flash的访问插入两个等待周期)
测试结果如下：
不对代码优化，在RAM中执行程序：sum1计数69467/秒
不对代码优化，在FLASH中执行程序：sum1计数43274/秒 (Flash里跑得慢)
/***********循环体内代码为N个以下的block*************/
(1)LDR R0,[PC, #0x154]
(2)LDR R1,[PC, #0x154]
(3)LDR R1,[R1,#0]
(4)ADDS R1, R1,#0x1
(5)STR R1,[R0, #0]
......
/****************************************************/
打开速度优化开关，在RAM中执行程序：sum1计数98993/秒
打开速度优化开关，在FLASH中执行程序：sum1计数115334/秒 (Flash里跑得快)
/***********循环体内代码为N个以下的block*************/
(1)LDR R1,[R1,#4]
(2)ADDS R1, R1,#0x1
(3)STR R1,[R0, #0]
......
/****************************************************/
结论就是：
1）程序运行在RAM里速度快还是运行在Flash里速度快，不是绝对的一概而论的，取决于代码；
2）就以上两种具体的代码情况来说，我觉得无优化时，如果在Flash里执行：(1)(2)的取指(读flash)->译码->执行 (读flash)；取指和执行阶段flash的目标地址不是连续的，因此是non-sequencial access，所以会很慢；
打开优化时，(1)(2)(3)都不会造成flash的non-sequential access，所以在flash里的优势（取指和取数据走不同的总线ICode和DCode以及Prefetch）就体现出来了。
再进一步的分析，又有这样一些结论：
没有优化时，指令执行时要到Flash中取常数，结果造成指令预取队列的取指中断，取完常数后需要重新填充指令预取队列，而Flash访问需要插入等待周期，当然时间就比较长了。
经过代码优化后，指令执行时不用再到Flash中取常数，指令预取队列不会被打断，而Flash访问需要插入等待周期的效应被下面贴子中介绍的取指缓冲区抵消，所以自然速度就快了；而这个时候在RAM中执行反而慢了是因为RAM不在ICode总线上，从RAM取指需要绕一圈，当然要比在ICode总线上的Flash慢了。
关于Flash的性能，请看我的另一篇分析：【分析】STM32从Flash中运行程序的时序分析
另外，STR9与STM32的总线架构是一样的，这里有一个在STR9上实现的FFT函数的实测数据，可以进一步说明在Flash中运行代码可以比在RAM中快！
在ST的网站上有一个DSP的函数库，这是它的文档《STR91x DSP library (DSPLIB)》，在这篇文档中有一节讨论FFT运算速度的，那里给出了实际的运算时间比较，摘录如下：
Radix-4
Complex FFT Operation Mode Cycle Count Microseconds
64 Point Program in Flash & Data in SRAM 2701 28.135
64 Point Program & Data in SRAM 3432 35.75
64 Point Program & Data in Flash 3705 38.594
256 Point Program in Flash & Data in SRAM 13740 143.125
256 Point Program & Data in SRAM 18079 188.323
256 Point Program & Data in Flash 19908 207.375