몇기가 넘는 파일 중간에 1바이트 끼워넣을때 그걸 몽땅 읽어와서 끼워넣고 다시 새 파일로 덮어씌우면 오래걸릴거아님
끼워넣기만 할 순 없는거임? 특정 위치에 쓰려고 하면 그 자리에 원래 있던게 대체돼버리던데
댓글 8
파일이 파편화가 돼서 그렇지 못할건 없잖나
익명(49.174)2021-03-14 23:31
?? 파일이 무슨 Sequential로 쭉 배치돼있는줄 암?
익명(59.13)2021-03-14 23:33
답글
시스템상 안된다는건 아는데 그럼 방법이 없냐는거지
익명(112.148)2021-03-14 23:35
파일 크기 변동이 제로이고 그냥 내용만 바뀐다면 변경 이벤트가 올 때 바뀐 부분만 수정할 수는 있지 근데 파일 크기가 1비트라도 바뀐다면 당연히 바뀐 부분부터 끝부분까지 재정렬해야 함. 변경된 부분만 바꾸는 것도 항상 효율적인 것은 아님. 파일 용량이 기가단위이면 효율적이겠지만 용량이 작으면 배보다 배꼽이 커짐.
익명(121.132)2021-03-14 23:38
답글
그래서 깃 같은 형상관리에서 변경된 내역을 별도의 파일로 관리하는 거임 이러면 파일에서 변경할 부분을 감지하는 오버헤드도 줄어들고 효율적이니까. 대신 공간효율에선 떨어지지.
익명(121.132)2021-03-14 23:40
답글
파싱과 raw 파일 데이터는 아예 별도로 보는 게 맞다. 파싱할 때 분석한 것의 파일 포인터 위치를 다 기억하는 코드 봤음? 그 파일 포인터 위치 찾는 오버헤드가 대단히 클 것임.
파일이 파편화가 돼서 그렇지 못할건 없잖나
?? 파일이 무슨 Sequential로 쭉 배치돼있는줄 암?
시스템상 안된다는건 아는데 그럼 방법이 없냐는거지
파일 크기 변동이 제로이고 그냥 내용만 바뀐다면 변경 이벤트가 올 때 바뀐 부분만 수정할 수는 있지 근데 파일 크기가 1비트라도 바뀐다면 당연히 바뀐 부분부터 끝부분까지 재정렬해야 함. 변경된 부분만 바꾸는 것도 항상 효율적인 것은 아님. 파일 용량이 기가단위이면 효율적이겠지만 용량이 작으면 배보다 배꼽이 커짐.
그래서 깃 같은 형상관리에서 변경된 내역을 별도의 파일로 관리하는 거임 이러면 파일에서 변경할 부분을 감지하는 오버헤드도 줄어들고 효율적이니까. 대신 공간효율에선 떨어지지.
파싱과 raw 파일 데이터는 아예 별도로 보는 게 맞다. 파싱할 때 분석한 것의 파일 포인터 위치를 다 기억하는 코드 봤음? 그 파일 포인터 위치 찾는 오버헤드가 대단히 클 것임.
그럭군
디스크 할당 단위만큼만 삽입하면 최적화 가능할거 같긴하네