Text 파1068; 크기가 100[MB]를 넘1012;ǐ12;1032; 파싱 ?
/196;그파1068;1060; ᓮ1;스트1064;데요, 사1060;1592;가 100MB가 넘lj16; 파1068;들도 1080;Ǻ12;요.
C/C++에서 ǖ16;1004;/196; 파1068;내용 올/140;서, 문1088;열 ,160;색/비교 መ1;1032; 함수를 써서 간단Ȣ16;,172; 한번 1676;봤lj16;데,
파1068;내용 올릴ǐ12; 시간1060; 1328; ,152;리고, 파싱속도도 생각보다 빠르1648;lj16; 않네요.
1060;런 파1068;1012; 파싱Ȣ16;/140;면 프/196;그ǖ16;1012; Ǻ12;떤식1004;/196; 1676;야 할까요 ?
사람 눈과 마우스/196; 수1089;업1008; 1208;대/196; 안.104;lj16; 양1077;니다...
// 서명
램에 매핑한 이후에 포인터 연산은 빠른편인데, 램에 매핑할때 시간이 좀 걸리네요. 요건 어쩔 수 없는 건가요 ?^^
절대 느리지 않습니다
Binary 검색도 빠른데 이게 느릴 이유가요ㅋ
메모리에 올린뒤에는 당연히 빠르지만요.
메모리 잡아서 읽는 것 보다는 획기적으로 빨랐던 걸로 기억합니다. 순차적으로 참조하면 계속 페이지 폴트나면서 (이 때마다 저장장치에서 읽으니까요. ) 느릴 순 있겠습니다만..
최초 접근시간이나 랜덤 액세스는 월등할텐데요?
요즘엔 해 본 적이 없어서 10년 이상 된 경험이긴 합니다.
각각 512가 지난경우, 다시 다음 부분의 512를 읽어 오는식을 추천드립니다.
100MB 텍스트 파일의 경우, 아무리 성능이 좋은 컴퓨터라도, 메모장에서 열면 로딩 시간이 걸리듯이
메모리에 올려서 검색, 비교는 조금 비효율적 입니다.
속도는 당연히(?) 생각보다 빠르지 않았습니다 윽.
파싱(?)하는데 더 시간을 많이 먹는다면, strstr()등의 C/C++ 함수보다는
lex/flex 등을 사용하여 특정 패턴을 찾는 함수를 생성해 쓰는것이 좀 더 빠릅니다.
찾는 패턴이 많을수록 차이가 많이 납니다. 최적의 오토마타를 생성하는 방식이기에.
완전 비정형데이터라면 단일 컬럼으로 해도 될거고요.
혹시 db를 다뤄보지 않으셨으면 ms office에 있는 access로 해도 일반 텍스트 검색보다는 훨씬 빠를겁니다.
이유는 잘 모르겠는데, 요즘에 DB를 안쓰려는 사람, 회사 등이 점점 많아지더군요.
비슷한 케이스 입니다.
어떻게 보면.. c나 node.js python 등으로 파싱 프로그램을 만들고
원하는 형태로 변형하여 원본 파일을 놔두고 편집본을 쓰시는건 어떨까요?