diff --git a/ImageSource/JSPatchMemory.png b/ImageSource/JSPatchMemory.png
new file mode 100644
index 0000000..795a12e
Binary files /dev/null and b/ImageSource/JSPatchMemory.png differ
diff --git a/ImageSource/JSPatchTimes.png b/ImageSource/JSPatchTimes.png
new file mode 100644
index 0000000..74bdb63
Binary files /dev/null and b/ImageSource/JSPatchTimes.png differ
diff --git a/ImageSource/MangoMemory.png b/ImageSource/MangoMemory.png
new file mode 100644
index 0000000..5679067
Binary files /dev/null and b/ImageSource/MangoMemory.png differ
diff --git a/ImageSource/MangoTimes.png b/ImageSource/MangoTimes.png
new file mode 100644
index 0000000..493b16d
Binary files /dev/null and b/ImageSource/MangoTimes.png differ
diff --git a/ImageSource/OCRunnerMemory.png b/ImageSource/OCRunnerMemory.png
new file mode 100644
index 0000000..0595976
Binary files /dev/null and b/ImageSource/OCRunnerMemory.png differ
diff --git a/ImageSource/OCRunnerTimes.png b/ImageSource/OCRunnerTimes.png
new file mode 100644
index 0000000..3d28131
Binary files /dev/null and b/ImageSource/OCRunnerTimes.png differ
diff --git a/README-CN.md b/README-CN.md
index 5ff487c..d2bc87a 100644
--- a/README-CN.md
+++ b/README-CN.md
@@ -242,12 +242,50 @@ CGRect CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat height)
 
 ## 性能测试
 
+### 加载时间
+
 ![2](https://silverfruity.github.io/2020/09/04/OCRunner/OCRunner_1.jpeg)
 
-* 目前递归方法调用的速度，大约为JSPatch的1/4倍，为MangoFix的15倍左右
-* OCRunner的补丁加载速度是JSPatch的20倍+，随着补丁大小的不断增加，这个倍数会不断增加
+### 执行速度和内存占用
+
+设备：iPhone SE2 , iOS 14.2,  Xcode 12.1.
+
+以经典的斐波那契数列函数作为例子，求第25项的值的测试结果.
+
+#### JSPatch
+
+* 执行时间，平均时间为0.169s
+
+  ![](./ImageSource/JSPatchTimes.png)
+
+* 内存占用，一直稳定在12MB左右
+
+
+![](./ImageSource/JSPatchMemory.png)
+
+#### OCRunner
+* 执行时间，平均时间为1.05s
+
+  ![](./ImageSource/OCRunnerTimes.png)
+
+* 内存占用，峰值为60MB左右
+
+
+![](./ImageSource/OCRunnerMemory.png)
+
+#### Mango
+* 执行时间，平均时间为2.38s。
+
+  ![](./ImageSource/MangoTimes.png)
+
+* 内存占用，持续走高，最高的时候大约为350MB。
+
+
+![](./ImageSource/MangoMemory.png)
 
-* 运行速度和内存占用与MangoFix差距不大。但应该会更优，OCRunner中MFValue的值采用union来实现，对象中不会有多个类型的实例变量。针对递归方法调用时的内存，目前存在内存占用过大的问题。
+* 目前递归方法调用的速度，大约为JSPatch的1/5倍，为MangoFix的2.5倍左右。
+* OCRunner的补丁加载速度是Mango的10倍+，随着补丁大小的不断增加，这个倍数会不断增加，针对JSPatch，目前未知。
+* 关于递归方法调用时的内存占用，目前存在占用过大的问题。求斐波那契数列数列第30项的时候，Mango会爆内存，OCRunner内存峰值占用大概在600MB。
 
 
 
diff --git a/README.md b/README.md
index ccfd1c0..cd128d5 100644
--- a/README.md
+++ b/README.md
@@ -229,11 +229,50 @@ CGRect CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat height)
 
 ## Performance Testing
 
-![image](https://raw.githubusercontent.com/SilverFruity/silverfruity.github.io/server/source/_posts/OCRunner/OCRunner_EN_1.jpeg)
+### Loading time
 
-* When testing with recursive functions, the performance of OCRunner is 1/4 times JSPatch's, and is 15 times Mango's.
-* OCRunner's patch loading speed is about 20 times + that of JSPatch, and this value increases as the patch size increases. 
-* The running speed and memory usage are not much different from MangoFix. The memory usage should be better. The value of MFValue in OCRunner uses malloc to copy the value, and there will be no multiple types of instance variables.
+![2](https://silverfruity.github.io/2020/09/04/OCRunner/OCRunner_1.jpeg)
+
+### Execution speed and memory usage
+
+Device:  iPhone SE2 , iOS 14.2,  Xcode 12.1.
+
+Take the classic Fibonacci sequence function as an example, find the test result of the value of the 25th term
+
+#### JSPatch
+
+* Execution time, the average time is 0.169s
+
+  ![](./ImageSource/JSPatchTimes.png)
+
+* Memory usage has been stable at around 12MB
+
+
+![](./ImageSource/JSPatchMemory.png)
+
+#### OCRunner
+* Execution time, the average time is 1.05s
+
+  ![](./ImageSource/OCRunnerTimes.png)
+
+* Memory usage, peak value is about 60MB
+
+
+![](./ImageSource/OCRunnerMemory.png)
+
+#### Mango
+* Execution time, the average time is 2.38s
+
+  ![](./ImageSource/MangoTimes.png)
+
+* The memory usage continues to rise, reaching about 350MB at the highest point.
+
+
+![](./ImageSource/MangoMemory.png)
+
+* When testing with recursive functions, the performance of OCRunner is 1/5 times JSPatch's, and is 2.5 times Mango's.
+* OCRunner's patch loading speed is about 20 times + that of Mango, and this value increases as the patch size increases.  and the result of JSPatch is unknown.
+* Regarding the memory usage of recursive method calls, there is currently a problem of excessive usage. When finding the 30th item of the Fibonacci sequence, Mango will burst the memory, and the peak memory usage of OCRunner is about 600MB.