브라우저에서 클라이언트 측에서 사용하기에 파이썬이 너무 느려 집니까?

17

파이썬이 브라우저에서 사용하기에는 너무 느리다는 진술을 들었습니다.

Javascript는 생존해야하기 때문에 빨리 필요로하고 빨리 만들어야하는 Google과 같은 회사 때문에이 측면에서만 우수하다고 생각하지만 잘못 될 수 있습니다.

브라우저에서 수행하는 방식에 영향을주는 Python 및 Javascript 설계 방식에 차이가 있습니까?

_{현재 클라이언트 측 Python 구현이 없기 때문에 내 질문은 누군가가 작성한 진술에서 비롯된 것이므로 언어 자체와 관련이있을 수도 있습니다 (믿지 않지만).}

— 프로 파치
소스

2

브라우저에서 파이썬? 언제 그런 일이 있었습니까?

— yannis

6

그렇지 않았다. 예고 would?

— Profpatsch

16

문제가 발생하지 않았다면 질문이 무엇인지 알 수 없습니다. 퍼포먼스를 말할 때, 언어에 관한 것이 아니라 언어의 구현에 관한 것입니다 (그리고 자바 스크립트와 마찬가지로 파이썬에도 몇 가지 구현이 존재합니다). 클라이언트 측 Python 구현이 없다면 무엇을 이야기해야합니까?

— yannis

1

이론 과학! : D 내 질문은 누군가가 한 진술에서 비롯된 것이므로 언어 자체와 관련이있을 수도 있습니다 (믿지는 않지만).

— Profpatsch

1

COM 인터페이스를 통해 Internet Explorer를위한 Python 통합 구현이 있었는데, VBScript 옵션으로 DOM을 스크립팅 할 수도있었습니다. MS는 버전 5 또는 6에서 COM 통합을 사용하는 옵션을 중단했다고 생각합니다.

— Martijn Pieters

23

우선 언어 와 구현을 명확히 구분해야합니다 . 언어는 추상적이며 구현은 성능을 측정 할 수있는 구체적인 것입니다. 예를 들어, Lisp는 실제 사용하기에는 너무 비효율적 인 것으로 여겨졌지만 컴파일러는 계속 성숙 해졌고 결국 전용 하드웨어가 개발되었습니다. 1980 년대의 어느 시점에서 그것은 고성능 워크 스테이션 개발을 위해 선택된 개발 플랫폼이었습니다.

즉, 가장 간단한 답변은 Google V8 과 같은 빠른 자바 스크립트 구현 이 표준 구현 인 Python (CPython)을 물 밖으로 날려 버리는 것입니다 . V8은 매우 빠른 JITer를 갖춘 고도로 최적화 된 가상 머신이며 CPython은 비교적 간단한 VM입니다. JIT를 사용하여 Python을 구현했지만 여전히 약 5-6 배 빠릅니다.

5 년 전에는 다른 이야기 였을 것입니다. 브라우저에 '실제'소프트웨어를 구축 한 사람이 없었기 때문에 속도가 문제가되지 않았기 때문에 브라우저는 단순한 자바 스크립트 구현을 가졌습니다.

— 숀 맥소 메이팅
소스

이것은 가장 통찰력있는 답변입니다. 따라서 시간과 돈이 아닌 잠재력이 있습니다.

— Profpatsch

7

"5 년 전에는 다른 이야기 였을 것입니다."... 그리고 5 년 후에는 다시 달라질 수도 있습니다.

— Bryan Oakley

1

>> 언어는 추상적 인 것, 구현은 성능을 측정 할 수있는 구체적인 것입니다. << 그렇습니다. 프로그래밍 언어 구현은 구체적입니다. 아니요, 프로그래밍 언어 구현에는 측정 가능한 속성 성능이 없습니다. 성능은 특정 상황에서 언어 구현을 사용하는 특정 프로그램의 속성입니다.

— igouy

2

@igouy 따라서 기능적으로 동일한 두 개의 프로그램을 작성하려면 (하나는 C, 하나는 Python), 성능 차이는 언어 구현이 아니라 응용 프로그램의 속성이라고 생각하십니까?

— ConditionRacer

1

@ConditionRacer : 동일한 프로그램을 작성하는 방법은 여러 가지가 있으므로 파이썬 버전의 프로그램이 C 버전과 다른 성능 특성을 가지고 있어도 C 버전과 동등한 파이썬 버전이 없음을 증명하지는 못합니다. asm.js ... 같은 언어를 모든 언어로 볼 수 있습니다. 거대한 배열을 사용하여 모든 프로그램의 상태를 저장할 수 있으며 언어의 기본 작업에서 쉽게 최적화 할 수있는 작은 하위 집합을 사용할 수 있습니다. (그들은 "모든 언어로 C를 쓸 수있다"고 말합니다.)

— Mankarse

5

웹의 오래된 시대에, 클라이언트 측 대화 형 컨텐츠 의 주된 형태 인 Java 애플릿이 사람들은 웹 페이지에서 애플릿과 상호 작용할 수 있도록 웹 페이지에서 양식을 가져 오는 방법이 필요하다는 것을 깨달았습니다.

이것으로부터, 자바 애플릿을 웹 페이지에 링크하기위한 스크립팅 언어는 이름이 javascript로 작성되었습니다.

[ 1 ], [ 2 ], [ 3 ] 과 같은 SO 질문과 애플릿에서 JavaScript 코드 호출 및 JavaScript 코드에서 애플릿 메소드 호출 과 같은 SO 질문으로이 유산의 흔적을 볼 수 있습니다 .

그러한 언어를 사용할 수있게되면서 당시의 브라우저 (주로 Netscape가 주된 언어)는 자바 스크립트를 경쟁 우위로 이용할 수있게했습니다 ( Netscape에서 설계된 자바 스크립트-Netscape는 '94 년에 서버를 보유한 최초의 서버 측 자바 스크립트였습니다. .js). 다른 브라우저가 뒤 따랐다. 사람들은 자바 스크립트를 사용하는 페이지를 작성하고있었습니다. 클라이언트 측 스크립팅에 대한 다른 시도는 작동하지 않는 것과 그렇지 않은 것 사이에 완전히 호환되지 않는 페이지를 의미합니다. 브라우저와 여기에 다른 사람들을위한 자바 스크립트 블록이 있습니다).

Netscape가 한동안 지배적 인 브라우저 였기 때문에 javascript가 사용되었습니다. 넷스케이프의 유산은 모질라 소스 파일의 각주로 잃어 버렸지 만, 자바 스크립트는 그대로 남아 있으며 그것을 대체 할 수있는 것은 아무것도 없습니다.

다른 클라이언트 슬라이드 스크립팅 언어의 경우 문제가 남아 있습니다. 자바 스크립트는 모든 브라우저에서 지원됩니다. 자바 스크립트가 아닌 파이썬 (예를 들어)을 지원하는 브라우저를 만들려면 대부분의 웹 사이트를 사용할 수 없습니다. 또한 해당 브라우저가 브라우저 트래픽의 상당한 부분을 차지하지 않는 한 웹 디자이너는 동일한 페이지에 대해 서로 다른 스크립팅 언어를 사용하여 두 페이지의 페이지를 만들고 싶지 않습니다.

vrml의 작동 방식과 유사하게 페이지에서 python 스크립트를 활성화 한 일부 브라우저 용 python 스크립팅 플러그인을 만들려고 할 수 있습니다. 그러나 vrml을 사용하는 웹 페이지를 들어 본 적이 없다면 다른 스크립팅 언어로 다른 웹 페이지를 사용할 가능성이 높습니다.

— 커뮤니티
소스

1

이것은“어떻게 전달 되었는가…”에 대한 아주 좋은 개요이며, 정답으로 표시하고 싶은만큼“오늘 왜 자바 스크립트가 클라이언트 측 언어입니까?”가 아니라“ 클라이언트 측에서 파이썬을 너무 느리게 만드는 디자인 문제가 있습니까?”

— Profpatsch

VRML ... 와우.

— FrustratedWithFormsDesigner

1

@Profpatsch는 자바 스크립트와 관련하여 기술적 인 측면에서 문제가되지 않습니다. 클라이언트 측 언어로는 사용하지 않는 것 외에는 아무 것도 사용하지 않으며 자바 애플릿과의 상호 작용을 포함하여 중요한 이점을 제공하지 않는 한 아무 것도 아닙니다. 문제는 기술적 인 것이 아니며 "javascript 왜"의 역사를 이해하지 않으면 "파이썬이 아닌 이유"에 대답 할 수 없습니다.

2

@MichaelT : 당신은 "클라이언트 측 언어가 되기에는 부적절한 자바 스크립트에 대한 기술적 디자인 문제가 없다"고 썼습니다. 당신은 JS가 아닌 파이썬을 의미합니까 ??

— Carl Smith

@CarlSmith Ahh 예. 내 실수 ... 그리고 특정 시간이 지난 후에는 주석을 편집 할 수 없습니다. 수정 해 주셔서 감사합니다.

4

나는 파이썬이 너무 느릴 것이라고 생각하지 않습니다. 적어도 JavaScript와 일치 할 정도로 빠르게 실행되는 것을 막는 언어에 대해서는 아무것도 없습니다. JavaScript로 컴파일 할 수 있으므로 브라우저에 컴파일러를 포함시키고 잠재적으로 페이지로드 시간을 늘릴 수 있습니다.

업데이트 : 파이썬에서 JS로 컴파일하는 것이 여기에 암시 된 것보다 훨씬 더 비싼 이유에 대해 아래 의견을 참조하십시오.

문제는 브라우저 공급 업체와 W3C가 먼저 Ruby 또는 다른 멋진 스크립팅 언어보다 Python을 선택한 다음 시스템 호출 등을 허용 할 수 없으므로 표준화 된 하위 집합을 정의 한 다음 잘 구현하도록 설득하려고합니다. 여전히 JavaScript를 지원합니다. 그런 일은 일어나지 않을 것입니다. 그러나 그렇게된다면 속도가 심각한 문제로 판명 될 것입니다.

— 칼 스미스
소스

7

첫 번째 요점은 따르지 않습니다. 모든 것이 기계 코드를 포함하여 거의 모든 것으로 컴파일 될 수 있지만, 언어 L로 작성되고 언어 C로 컴파일 된 프로그램이 언어 C로 작성된 동등한 프로그램만큼 빠르다는 것을 의미하지는 않습니다.

1

CoffeeScript는 기본적으로 JavaScript와 동일한 핵심 개념에 대한 다른 구문이며 C는 기본적으로 이식 가능한 어셈블리 언어입니다. 반면에 파이썬과 자바 스크립트는 상당히 다릅니다. Python을 올바르게 구현하려면 클래스 모델, 연산자 오버로드, 메타 클래스 등을 지원해야하며 (수십억 개가 넘는) 메타 데이터를 쉽고 효율적으로 매핑하지 않습니다. C 또는 머신 코드로 컴파일하는 것과 같은 문제가 있습니다. JIT를 전문화하는 것이 유일한 희망일 수 있지만 JS를 대상으로하는 JIT 컴파일러는 아직 실용성이 입증되지 않았습니다.

3

한 가지 문제는 JS와 마찬가지로 Python을 압축 할 수 없다는 사실입니다. 모든 공백과 줄 바꿈을 제거하고 범위를 지정하십시오! 따라서 중요한 파이썬 덩어리에 대해로드 시간이 길어집니다.

— TMN

1

@TMN 재미있는 점이지만, 파이썬의 표현성 이 그것을 완화시키기 위해 먼 길을 갈 것이라고 희망 할 것입니다.

— Daniel B

2

@TMN Daniel B의 말과 gzip은 차이를 줄여야합니다. 아, 그리고 파이썬은 새로운 줄과 공백을 필요로하지 않습니다. (모두는 아니지만) 많은 라인은 예를 들어 파이썬에서 잘 함께 결합 할 수 a = something(); frobincate(a); return quux및 if condition: react()한 줄의 각이다. 그리고 n 들여 쓰기 레벨은 n * 4 공백이 아닌 n 공백 만 필요합니다.

2

파이썬에는 자체 가상 머신이 있다고 생각합니다. 파이썬에 대한 경험이 많지 않지만 최적화되지 않은 JavaScript 엔진만큼 성능이 좋지 않은 이유는 없습니다.

임의의 생각 :

(1) Jython을 사용하여 Java 애플릿을 통해 로컬로 Python을 실행할 수 있습니다. 여기서 볼 수있는 어려운 부분은 애플릿이 매우 제한적이므로 액세스 제한에 맞게 Jython을 수정해야 할 수도 있습니다. 예를 들어, 로그 파일에 쓰는 경우 로깅 코드를 제거해야 할 수 있습니다. 애플릿이 눈에 띄게 표시 될 필요는 없습니다.

(2) 누군가가 Python-to-JavaScript "컴파일러"/ 변환기를 만들 수 있습니다. 이것은 많은 작업이 될 것입니다.

— 아론 S
소스

5

Someone could build a Python-to-JavaScript "compiler"/converter글쎄, 누군가가 이미했다 .

— yannis

Brython 도

— 세계 엔지니어

나는 이것을 직접 할 필요는 없었지만 Jython을 사용하여 Java 애플릿을 작성한 사람들을 알고 있습니다. 즉 같은 것이 아니다 파이썬 브라우저에서 자바 스크립트를 교체하는 것처럼.

— Martijn Pieters

Brython적어도 페이지에서 다소 고립 된 부분에 대해서는 흥미롭게 빠르게 작동합니다 (와의 낮은 상호 작용 DOM tree).

— Profpatsch

@Profpatsch 지난번 보았을 때, 파이썬 언어의 큰 부분조차 구현하지 않았습니다. 편리하게 구현되지 않은 기능 중에는 JavaScript 위에 구현하기 어려운 기능이 있습니다. PyPy 저자 중 하나를 역설하면, 파이썬의 사소한 부분 집합을 빠르고 쉽게 만들 수 있습니다. 전체 파이썬은 어려운 곳입니다.

1

언어의 구현에 달려 있으며 반드시 언어 자체는 아닙니다. 대부분의 JavaScript 해석기는 거의 모든 Python 구현보다 훨씬 빠릅니다.

이것은 파이썬 언어가 JavaScript와 거의 같은 속도로 사용될 수 없다는 것을 의미하지는 않습니다. Opal은 Ruby 코드를 클로저로 싸인 JavaScript 코드로 컴파일하여 브라우저에서 거의 완전한 Ruby 언어 및 표준 라이브러리를 구현합니다. Opal 라이브러리를 포함하는 오버 헤드를 제외하고 속도는 내가 아는 다른 Ruby 인터프리터보다 일반 JavaScript의 속도에 훨씬 가깝습니다.

파이썬에 Opal과 동등한 것이 있는지는 모르겠지만 그러한 프로젝트는 아마도 귀하의 질문에 대한 대답이 "아니오"라는 것을 의미합니다. JavaScript를 "웹용 어셈블리 언어"로 사용함에 따라 다른 언어, 특히 모바일 컴퓨팅 성능이 향상되고 언어 오버 헤드가 증가함에 따라 점점 더 많은 언어를 플랫폼으로 사용할 것인지에 대해 놀라지 않을 것입니다. JavaScript로 구현되는 것은 점점 더 무시됩니다.

편집 : 다음은 JavaScript에서 컴파일 / 실행하는 브라우저의 Python 구현 목록입니다.

https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js#python

관심이 있으시다면 오팔을 확인해보세요.

http://opalrb.org/

브라우저가 별도의 인터프리터를 지원할 것이라고 의심하기 때문에 이러한 컴파일러는 아마도 JavaScript 이외의 언어를 사용하는 측면에서 미래의 방법 일 것입니다. 지금도 대부분의 영역에서 비슷한 성능을 얻을 수 있습니다. 그러나 이것은 내 의견이므로 명심하십시오.

— 까마귀
소스

0

이 질문을했을 때조차도 오늘날 웹 페이지에서 사용할 수있는 많은 파이썬 구현이 이미 자바 스크립트로 제공되었습니다.

한 번 봐 가지고 http://www.skulpt.org/ 또는 http://www.brython.info/ 스타터를.

성능이 그렇게 나쁘지는 않지만 직접 테스트하고 알아 내야합니다.

— 팹 스프로
소스

-4

Python은 서버에서 실행되는 "콘솔"언어입니다.

자바 스크립트는 클라이언트에서 실행되는 "브라우저"언어입니다.

따라서 그들은 직접 경쟁하지 않습니다

... 물론 node.js 및 아마도 python 브라우저 플러그인이 있지만 특정 구현에 대한 성능에 대한 질문입니다.

또한 대부분의 응용 프로그램에서 파이썬은 일종의 광범위한 계산을 수행하고 CPU 사이클을 짜 내야하는 경우를 제외하고는 잘 수행됩니다.

마지막으로, 파이썬과 자바 스크립트는 많은 유사점을 공유합니다. 동적 특성으로 인해 런타임시 해석해야하며 정적 유형 언어만큼 강력하게 컴파일 할 수 없습니다. 따라서 달성 가능한 성능이 비슷하다고 가정합니다.

— 자그마한
소스

2

서버 측 자바 스크립트는 94 년경에있었습니다. jsc콘솔에서 자바 스크립트로 작업 할 수 있습니다 python. 콘솔에서 입력 할 때와 거의 동일 합니다.

@MichaelT : 좋아, 나는 이에 따라 나의 반응을 편집했다

— dagnelies

2

또한 당신은 파이썬으로 데스크탑 앱을 작성할 수 있습니다 .... 나는 당신이 구별하는 진정한 이유를 보지 못합니다.

— Chris Travers

또한 3D 모델링 도구 인 Blender는 UI에서 메쉬 생성에 이르는 모든 작업에 Python을 사용합니다. 그것이 경쟁적으로 경쟁력이 없다면, 무엇입니까?

— Andrew Gray

@Chris : 차이점은 자바 스크립트는 주로 브라우저 기술이며, 파이썬은 주로 데스크탑 / 콘솔 기술입니다. 내 요점은 두 가지를 비교하는 것이 전혀 다른 목적으로 작용하기 때문에 거의 의미가 없다는 것입니다.

— dagnelies