저는 메모리가 매우 작은 모바일 플랫폼 소프트웨어를 개발 중입니다. I/O 병목 현상의 경우, seek 연산을 사용하여 img 파일에서 몇 바이트를 읽어야합니다 (memmry에서 직접 읽는 것보다 seek가 약 10 배 정도 느릴 것이라고 가정 할 수 있음). 필자의 테스트에서이 함수는 7480325 번 호출되었고 bytes_offset 6800에서 130000으로 바이트를 읽음으로써 모든 바이트가 평균 100 번 읽혔다 (일부 바이트는 3 ~ 4 번, 1000 번 이상 읽혔다).LRU 제한된 크기의 C로 된 캐시 디자인
아래는 제 통계입니다.
bytes offset 6800 ~ 6900: 170884 times
bytes offset 6900 ~ 7000: 220944 times
bytes offset 7000 ~ 7100: 24216 times
bytes offset 7100 ~ 7200: 9576 times
bytes offset 7200 ~ 7300: 14813 times
bytes offset 7300 ~ 7400: 22109 times
bytes offset 7400 ~ 7500: 19748 times
bytes offset 7500 ~ 7600: 43110 times
bytes offset 7600 ~ 7700: 157976 times
...
bytes offset 121200 ~ 121300: 1514 times
bytes offset 121300 ~ 121400: 802 times
bytes offset 121400 ~ 121500: 606 times
bytes offset 121500 ~ 121600: 444 times
bytes offset 121600 ~ 121700: 398 times
max_bytes_offset 121703
min_bytes_offset 6848
그런 다음 I/O 성능을 향상시키기 위해 LRU 스키마를 사용하여 캐시를 작성하려고합니다. 다른 사람들의 질문에서, 나는 해시 테이블 + 이중 연결리스트가 좋은 방법이라는 것을 발견했다. 그러나 최선의 방법으로 내 문제를 개선하기위한 구조를 만드는 방법은 무엇입니까? 1300 개의 버킷을 만들 계획이며 모든 버킷은 최대 크기가 10 인 이중 연결 목록을 소유하고 있습니다. 그런 다음 총 메모리는 약 13KB입니다. 구현 및 유지 관리는 간단하지만 효율이 가장 좋지 않다고 생각합니다.
내 통계에는 간격이 약간있는 반면 오프셋 간격이 더 많은 조회수 비율이 있습니다. 통계를 적용 할 수있는 구조를 만들려면 어떻게해야합니까?
키를 검색 할 때 크기가 10 인 전체 목록을 탐색해야합니다. 검색 효율이 높은 다른 방법이 있습니까?
일부 모바일 플랫폼에서는 캐시가 더 많은 메모리를 사용할 수 있지만 다른 플랫폼은 더 적은 메모리를 사용할 수 있습니다. 버킷의 크기를 변경하는 것을 제외하고 허용 된 메모리 변경 사항을 적용하도록 캐시를 만들려면 어떻게해야합니까?
카페의 방법이 더 좋은 것처럼 보입니다. 큰 이중 연결 목록과 큰 해시 테이블을 사용하여 키를 노드 항목에 매핑하는 것이 더 적합하며 LRU를 더 많이 활용합니다. 그러나 해시 함수를 설계하는 것은 어려운 문제가되고 있습니다. 당신은 단지 당신이 가능성이 이중 연결리스트와 분배 더 나을 것, 각 버킷에 10 개 항목의 최대를 가질려고하는 경우에 나는 당신의 제안을 기다리고 있어요
는 ~
예상되는 지역 편향치가 있습니까? 그것에 관한 어떤 통계? – caf
두 개의 읽기 바이트 사이의 관계를 의미합니까? img 파일은 트리 구조를 저장하기 때문에 관계가 없다고 가정 할 수 있습니다. – lucas
나는 실수를했다. 예상 지역이 있습니다. 통계를 연구 중입니다. – lucas