diff --git a/README.md b/README.md
index 13bd8deaa3c828dbdee5b0475bff55e2d9f982b4..99e223e258790c69d6fcc1e97229f9d635fb59ea 100644
--- a/README.md
+++ b/README.md
@@ -502,3 +502,28 @@ int main()
 >> * (gdb) watch : 변수가 변경 될 때 프로그램을 중단하기 위해 변수에 감시점을 설정한다. 프로그램 실행 중에 변수가 어떻게 변경되는지 자동으로 인쇄할려면 디스플레이를 사용하면 된다. watch 사용시 변수의 값이 바뀔 때 마다 실행을 중지할 수 있다. 
 
 
+## lesson 10
+
+* 저번 실습에서 $cc -g 를 하여 coredump 에러가 났음에도 coredump.c 파일을 찾지 못했었다. 
+* 이러한 이유는 coredump파일은 용량이 매우 커서 /var/lib/apport/coredump/ 에 자동으로 저장이 되고 있었기 때문이다. 
+> * *core dump : 메모리들의 stack 등이 생긴것을 모두 dump 시켜서 에러가 났을 때의 메모리 상태를 볼 수 있게 해준다. 
+> * 이러한 core dump 파일들은 위에서 말했듯이 용량이 크므로 나중에 다 지우는 것이 좋다. 
+> * 해당 경로에서 coredump 파일에 대해 $gdb a.out "파일네임" 을 하면 어디서 에러가 났는지 보여준다. 
+
+1. 컴퓨터에서의 속도
+> * 속도가 빠른 순서는 cpu에서 연산 > memory 에서 가져오기 > storage에서 가져오기 > I/O에서 가져오기 이다. 
+> * cpu, cache, memory 에서 가장 속도가 빠른 순서는 cpu에 있는 register > cache > memory 순이다. 
+> * disk block에 조각 모으기 : 연속된 data 모음.. 성능이 좋음(HDD의 경우만), SSD의 경우에는 조각모으기를 하지 않아도 빠르게 access가능하다. 
+
+2. gprofile 하는 방법
+> 1. $cc -pg test.c 
+> 2. a.out
+> 3. gprof a.out gmon.out
+> * 마지막 명령어를 실행하면 아래와 같은 여러 가지 정보를 볼 수 있다. 
+>> * Call graph (explanation follows)
+>>> * time과 called name 등을 보여준다.
+>>> * 이것 확인시 for loop의 i를 조금씩만 증가시켜서 많은 call을 하여 확인하는 것이 좋다. 
+>> * 시간계산
+>>> * 같은 코드여도 함수의 call을 줄이거나 늘리면 시간 계산이 또 달라진다. 
+>>> * 또한 오버플로우를 방지하기 위해 long long으로 a,b를 받아 곱하고 두 수의 곱을 int로 변환하여 받은 다음 gprof를 하여 시간계산 한 것을 확인하면 시간이 더 걸린 것을 볼 수 있다. 
+>>> * 위와 같은 것들은 오차가 넓기 때문에 5번 이상 돌려서 통계를 내어 사용하는 것이 좋다.