diff options
| -rw-r--r-- | docs/research/109-finding-items.md | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/docs/research/109-finding-items.md b/docs/research/109-finding-items.md index ffa3c25..3557650 100644 --- a/docs/research/109-finding-items.md +++ b/docs/research/109-finding-items.md @@ -37,7 +37,8 @@ W=1의 재고는 항목 10만 개, 수 필드 다섯이다. 잎만 4 MB라서 � - **넣지 않았다.** 미리 가져오기는 마이크로벤치에서 찾고 읽기를 10만 항목에서 20% 빠르게 했다. 그러나 TPC-C에서는 깨끗한 쌍 셋이 +2.1%, +1.5%, −0.6%였고, 거래당 CPU가 준 것은 여섯 쌍 가운데 둘이었다. 기준(다섯 쌍, +3%)에 한참 못 미친다. - 게다가 찾기만 하는 경우(`has`)를 48% 느리게 한다. 쓰지 않을 줄을 가져오느라 메모리의 줄을 차지하기 때문이다. + 게다가 찾기만 하는 경우(`has`)를 48% 느리게 한다. 쓰지 않을 줄을 가져오느라 메모리의 요청 자리를 차지하는 것으로 + 보인다(재지는 않았다). - **가설이 틀렸다.** 필드를 열로 나눠 들어 한 항목의 필드가 여러 캐시 줄에 흩어지니 그것이 비싸리라 봤다. 마이크로벤치에서는 맞았다(10만 항목에서 필드 셋을 읽는 데 208 ns, 찾기의 두 배 가까이). 그러나 TPC-C의 소유자 표본에서 "찾기" 20개 가운데 18개는 `pure_list_seek` 안, 곧 트리를 내려가는 걸음이었고, 필드 읽기는 2개였다. @@ -79,6 +80,7 @@ W=1의 재고는 항목 10만 개, 수 필드 다섯이다. 잎만 4 MB라서 � ## 판정 - 기준 셋 가운데 둘(TPC-C, 그리고 40만 항목의 마이크로벤치)을 채우지 못했다. 넣지 않는다. 코드는 바뀌지 않았다. +- 은행 질의(훑기)는 재지 않았다. 앞의 두 기준에서 이미 넣지 않기로 정해졌기 때문이다. ## 다음 |