← 질문 목록
#356깊이 0
큰 파일을 통째로 읽으면 무엇이 문제인가?
파일 크기에 비례해, 대개는 그보다 더 메모리를 잡는다. 남은 것을 넘기면 할당에 실패하거나 프로세스가 강제로 끝난다.
| 순서 | 통째로 읽기 | 흘려 읽기 |
|---|---|---|
| 1 | 전체를 메모리에 올린다 | 한 조각을 읽는다 |
| 2 | 다 올라올 때까지 기다린다 | 그 조각을 처리해 내보낸다 |
| 3 | 처리한다 | 다음 조각을 읽는다 |
| 4 | 내보낸다 | 계속 반복한다 |
더 든다고 적은 이유가 있다. 읽어 온 바이트를 문자열이나 객체로 바꾸면 그만큼이 또 든다. 파일 크기만 보고 여유를 재면 모자란다.
주의
메모리가 넉넉해도 값을 치른다. 같은 일을 동시에 열 명이 하면 열 배를 잡는다. 혼자 시험하면 이 한계가 안 보인다.
첫 응답도 늦어진다. 통째로 읽는 쪽은 마지막 바이트가 도착해야 일을 시작하는데, 흘려 읽으면 첫 조각부터 내보낼 수 있다.
그래서 업로드와 다운로드, 큰 결과 집합은 흘려 보낸다. 읽는 쪽과 쓰는 쪽을 이어 두고 조각 단위로 넘긴다.
정렬처럼 전체를 봐야 하는 일은 흘려 보내기만으로 안 된다. 들어가는 만큼씩 나눠 처리하고 나중에 합치는 방식으로 바꾼다.
메모리 사용량이 입력 크기에 비례하는지 봐야 한다. 비례하면 입력이 커질 때 그대로 무너진다.
추천 꼬리질문
관련 질문
- 읽은 파일이 두 번째부터 빨라지는 이유는?운영체제둘 다 파일 읽기와 메모리(페이지 캐시) 사이의 관계를 다룬다.
- 메모리보다 큰 데이터를 정렬할 때 무엇을 쓰는가?자료구조 · 알고리즘메모리에 다 올라가지 않는 데이터를 다룬다는 같은 전제에 서 있다 — 외부 정렬이 그 해법의 대표다.
- 보낼 데이터가 길에서 감당할 크기보다 크면 어떻게 되는가?네트워크감당 못 할 크기를 조각으로 나눠 다룬다는 같은 해법을 쓴다 — 한쪽은 메모리가, 한쪽은 전송 경로가 한계다.
- 즉시 로딩을 기본값처럼 쓰면 왜 위험한가?프레임워크
- 목록 하나 읽었는데 쿼리가 백 번 나가는 이유는?프레임워크