루핑 및 확장된 성능

복잡

다음은 때때로 유효합니다.

gzip -d `cat large_file_list`

세 가지 문제는 ( bash대부분의 Bourne 유사 쉘에서) 다음과 같습니다.

1. 파일 이름에 공백 탭이나 개행 문자가 포함되어 있으면 실패합니다( $IFS수정되지 않았다고 가정). 그 이유는 껍질 때문이에요분사.

2. 파일 이름에 전역 활성 문자가 포함된 경우에도 실패할 수 있습니다. 쉘이 적용되기 때문입니다.경로명 확장파일 목록에

3. 파일 이름이 -( POSIXLY_CORRECT=1첫 번째 파일에만 적용되는 경우)로 시작하거나 파일 이름이 -.

4. 하나의 명령줄에 들어갈 수 없을 정도로 파일 이름이 너무 많으면 실패합니다.

아래 코드는 위 코드와 동일한 문제가 있습니다(네 번째 코드 제외).

for file in `cat large_file_list`
do
    gzip -d $file
done

안정적인 솔루션

한 줄에 하나의 파일 이름만 있고 large_file_list이름이 지정된 파일이 -그 중에 없으며 GNU 시스템을 사용하는 경우 다음을 사용하십시오.

xargs -rd'\n' gzip -d -- <large_file_list

-d'\n'xargs각 입력 줄을 별도의 파일 이름으로 처리하도록 지시합니다 .

-rxargs입력 파일이 비어 있으면 명령을 실행하지 않도록 지시합니다 .

--gzip다음 인수는 로 시작하더라도 옵션으로 간주되지 않음 을 나타냅니다 -. 개별 파일은 호출되는 -대신 계속 고려됩니다 .--

xargs각 명령줄에 여러 개의 파일 이름이 지정되지만 그 수는 명령줄 제한을 초과하지 않습니다. 이렇게 하면 프로세스를 시작해야 하는 횟수가 줄어들어 gzip속도가 더 빨라집니다. 또한 안전합니다. 파일 이름도 보호됩니다.분사그리고경로명 확장.

이것이 중요할지는 의문이다.

목록 파일에 얼마나 많은 파일이 나열되어 있는지 모르기 때문에 루프를 사용하고 파일 이름에 공백이 있는지 (보통) 모르기 때문입니다. 매우 긴 인수 목록을 생성하는 명령 대체를 수행하면 결과 목록 길이가 너무 길면 "인수 목록이 너무 김" 오류가 발생할 수 있습니다.

내 루프는 다음과 같습니다

while IFS= read -r name; do
    gunzip "$name"
done <file.list

또한 gunzip명령 뒤에 데이터 처리를 위한 명령을 삽입할 수도 있습니다. 실제로 데이터의 실제 내용과 이를 통해 수행해야 하는 작업에 따라 파일에 저장하지 않고 처리하는 것이 가능할 수도 있습니다.

while IFS= read -r name; do
    zcat "$name" | process_data
done <file.list

( process_data표준 입력에서 압축되지 않은 데이터를 읽는 파이프는 어디에 있습니까)

데이터 처리가 압축 해제보다 오래 걸리는 경우 루프가 더 효율적인지에 대한 질문은 부적합해집니다.

이상적으로는, 나는 파일 이름 목록을 다루지 않고 다음과 같은 파일 이름 글로빙 패턴을 사용하고 싶습니다.

for name in ./*.gz; do
    # processing of "$name" here
done

./*.gz문제의 파일과 일치하는 몇 가지 패턴이 있습니다. 이렇게 하면 파일 수나 파일 이름에 사용된 문자(줄 바꿈이나 기타 공백 문자를 포함하거나 대시로 시작할 수 있음 등)에 의존하지 않습니다.

관련된:

• "IFS=read-r-line" 이해

두 가지 중에서 모든 파일을 한 번의 호출로 전달하는 것이 gzip더 빠를 것입니다. 정확히 한 번만 시작하면 되기 때문입니다 gzip. (즉, 명령이 전혀 작동한다면 주의 사항에 대한 다른 답변을 참조하세요.)

하지만 제가 모두에게 상기시키고 싶은 것은최적화의 황금률:이 작업을 조기에 수행하지 마십시오.

1. 문제가 있다는 것을 알기 전까지는 이런 종류의 작업을 최적화하지 마십시오.

   이 과정에서 시간이 오래 걸리나요? 글쎄, 대용량 파일의 압축을 풀면 아마 그럴 것이고, 어쨌든 그렇게 해야 하기 때문에 대답하기가 그리 쉽지 않을 수도 있습니다.

2. 측정하다.사실, 그것이 확실히 아는 가장 좋은 방법입니다.

   결과는 직접 눈으로 확인하거나(또는 스톱워치를 사용하여) 다음에 적용됩니다.당신의 상황인터넷의 무작위 답변은 아마도 그렇지 않을 것입니다. 이 두 가지 변형 을 스크립트에 넣고 실행합니다 time script1.sh. time script2.sh(빈 아카이브 목록을 사용하여 오버헤드의 절대량을 측정합니다.)

당신의 디스크는 얼마나 빠른가요?

이 작업은 CPU를 모두 사용해야 합니다.

parallel -X gzip -d :::: large_file_list

따라서 한계는 디스크 속도일 수 있습니다.

다음을 조정해 볼 수 있습니다 -j.

parallel -j50% -X gzip -d :::: large_file_list

이는 이전 명령과 같이 작업의 절반을 병렬로 실행하고 디스크에 부담을 덜 주므로 디스크에 따라 속도가 더 빨라질 수 있습니다.