컴파일된 쉘 스크립트의 성능이 더 좋습니까?

제목의 질문에 답하기 위해, 컴파일된 쉘 스크립트는 성능을 향상시킬 수 있습니다. 즉, 스크립트의 명령을 반복해서 재해석할 필요 없이 컴파일된 결과가 해석된 결과를 나타내는 경우입니다. 예를 들어 참조하십시오.ksh93~의shcomp또는zsh~의zcompile.

그러나 shc스크립트는 이런 방식으로 컴파일되지 않습니다. 실제로는 컴파일러가 아니라 효율성이 의심스러운 다양한 보호 기술을 갖춘 스크립트 "암호화" 도구입니다. 컴파일된 스크립트를 사용하면 shc결과는 실행 시 내용을 즉시 읽을 수 없는 바이너리 파일이 되며, 내용을 해독하고 해독된 스크립트를 사용하여 스크립트가 사용하려는 도구를 실행하여 원본 스크립트를 쉽게 만듭니다. 검색 가능(비교를 찾기 어렵게 만들기 위해 추가 공백을 포함하여 인터프리터의 명령줄에서 전체가 전달됩니다.) 따라서 전반적인 성능은 항상 나빠집니다. 원본 스크립트를 실행하는 데 필요한 시간 외에도 환경을 설정하고 스크립트를 해독하는 데 필요한 시간도 있습니다.

인터넷 검색 후 BASH 스크립트를 바이너리 실행 파일로 컴파일하는 방법을 찾았습니다 shc(

shc이 장치가 수년 동안 철저하게 사실이 아님이 밝혀졌음에도 불구하고 이 장치가 여전히 Google 검색 결과에 나타나는 것은 매우 불행한 일입니다 . 이 장치 shc는 컴파일러가 아니며스크립트 소스 코드를 보고 "도용"하는 것을 막지는 못합니다..

shc는 스크립트 소스를 대조한 후 이를 인수로 전달하기 때문에 필요 이상으로 멍청합니다. 즉, 스크립트를 실행하는 사용자뿐만 아니라 모든 사용자에게 표시된다는 bash -c의미입니다 . /proc/<pid>/cmdline이는 또한 단일 명령줄 인수 길이(128k 바이트)에 대한 Linux 제한에 도달합니다. 그런데 더 우스꽝스러운 점은 인수의 첫 번째 부분이 공백으로 채워져 표시되지 않는다는 것입니다 ps;-)

어떤 식으로든 내 스크립트의 성능이 향상됩니까?

예, 스크립트가 전혀 작동하지 않을 수 있습니다. 즉, 스크립트가 더 빨리 종료된다는 의미입니다.

일반적으로 말하면, 런타임에 새로운 소스 텍스트를 도입하여 컴파일 단계를 우회하는 방법이 많기 때문에 쉘 스크립트를 컴파일할 방법이 없습니다. 새 소스는 컴파일된 함수나 변수와 상호 작용할 수 없습니다.

런타임 소스를 생성하는 두 가지 방법은 다음과 같습니다.

원본 스크립트가 컴파일된 이후 생성되거나 수정되었을 수 있는 보조 파일을 가져옵니다.

문자열로 임의의 명령을 구성하고 런타임에 실행합니다.