Python, Tarayıcılarda istemci tarafı kullanımı için çok yavaş olur mu?

17

Python'un tarayıcılarda herhangi bir kullanım için çok yavaş olacağını ifade ettim.

Javascript'in bu açıdan sadece Google'a hızlı ihtiyaç duyan (ve hızlı hale getiren) şirketler nedeniyle hayatta kalmaları gerektiğinden üstün olduğunu düşünüyorum, ancak yanlış olabilirim.

Python ve Javascript'in nasıl tasarlandıkları konusunda tarayıcılarda nasıl performans gösterecekleri (etkisi) üzerinde herhangi bir fark var mı?

_{Şu an itibariyle bir istemci tarafı Python uygulaması olmadığından, sorum birisinin yaptığı açıklamadan geliyor, bu yüzden belki de dillerin kendisi ile bir ilgisi var (buna inanmama rağmen).}

— Profpatsch
kaynak

2

Python tarayıcıda mı? Bu ne zaman oldu?

— yannis

6

Olmadı. Dikkat edin would?

— Profpatsch

16

Eğer olmadıysa, sorunun ne hakkında olduğunu göremiyorum. Performanstan bahsederken, diller hakkında değil, dil uygulamaları hakkında konuşuyoruz (ve Python için Javascript için olduğu gibi birkaç uygulama var). İstemci tarafı Python uygulaması yoksa, konuşacak ne var?

— yannis

1

Teorik Bilim! : D Sorum birisinin yaptığı açıklamadan geliyor, bu yüzden belki de dillerin kendisi ile bir ilgisi var (buna inanmama rağmen).

— Profpatsch

1

Bir kez Internet Explorer için DOM arabirimi için bir VBScript seçeneği de etkinleştiren COM arabirimi aracılığıyla bir Python entegrasyonu uygulaması vardı. MS sürüm 5 veya 6 COM entegrasyonu kullanma seçeneği durdu düşünüyorum, hatırlayamıyorum.

— Martijn Pieters

23

Başlangıç olarak, diller ve uygulamalar arasında net bir ayrım yapmalıyız . Bir dil soyut bir şeydir, uygulama performansı ölçülebilen somut bir şeydir. Örneğin, Lisp bir zamanlar pratik kullanım için çok verimsiz olarak kabul edildi, ancak derleyiciler olgunlaşmaya devam etti ve sonunda bunun için özel donanım geliştirildi; 1980'lerde bir noktada, yüksek performanslı iş istasyonu geliştirme için tercih edilen geliştirme platformuydu.

Bununla birlikte, en basit cevap, Google'ın V8'i gibi hızlı bir Javascript uygulamasının standart Python (CPython) uygulamasını sudan atmasıdır . V8, oldukça hızlı bir JITer ile son derece optimize edilmiş bir sanal makinedir, CPython ise oldukça basit bir sanal makinedir. Bir JIT ile Python uygulaması var ama bu hala sadece 5-6 kat daha hızlı.

Beş yıl önce farklı bir hikaye olurdu. Tarayıcılar basit Javascript uygulamalarına sahipti çünkü kimse onunla 'gerçek' bir yazılım inşa etmediğinden ve Python daha hızlı olmasa bile eşit olacaktı çünkü hız bir endişe değildi.

— Sean McSomething
kaynak

Bu şimdiye kadarki en anlayışlı cevap. Yani potansiyel değil, zaman ve para.

— Profpatsch

7

“Beş yıl önce farklı bir hikaye olurdu” ... ve bundan beş yıl sonra yine farklı olabilir.

— Bryan Oakley

1

>> Bir dil soyut bir şeydir, uygulama performansı ölçülebilen somut bir şeydir << Evet, bir programlama dili uygulaması somut bir şeydir. Hayır, bir programlama dili uygulamasının ölçülebilir bir özellik performansı yoktur. Performans, belirli bir bağlamda bir dil uygulaması kullanan belirli programların bir özelliğidir.

— igouy

2

@igouy Yani biri C, diğeri Python olmak üzere iki işlevsel olarak özdeş program yazacak olsaydım, performans farkının dil uygulaması değil, uygulamanın bir özelliği olduğunu düşünürdünüz?

— ConditionRacer

1

@ConditionRacer: Aynı programı yazmanın birçok farklı yolu vardır, bu nedenle programın bir python sürümü bir C sürümünden farklı performans özelliklerine sahip olsa bile, hiçbir python sürümünün C sürümüne eşdeğer olamayacağını kanıtlamaz. Asm.js gibi şeyleri görün ... herhangi bir dilde, programınızın tüm durumunu depolamak için dev bir dizi kullanabilir ve dilin ilkel işlemlerinin kolayca optimize edilebilen küçük bir alt kümesini kullanabilirsiniz. (Dedikleri gibi "herhangi bir dilde C yazabilirsiniz").

— Mankarse

5

Web'in eski zamanlarında, istemci tarafı etkileşimli içeriğinin ~~ana~~ tek biçiminin bulunduğu java uygulamaları , web sayfasındaki uygulamalarla etkileşime girebilmek için bir web sayfasında form almanın bir yolu olması gerektiğini fark ettiğinde.

Buradan, java uygulamasını web sayfasına bağlamak için bir betik dili ... javascript adıyla oluşturuldu.

Bir gibi SO sorularla bu mirasın izlerini görebilirsiniz [ 1 ], [ 2 ], [ 3 ] - ve iki resmi belgeler: Bir Applet itibaren çağırma JavaScript kodu ve JavaScript Kod Kimden çağırma Applet Yöntemleri

Böyle bir dil mevcut olduğunda, tarayıcılar (Netscape baskın olanıdır) javascript'i rekabetçi bir avantaj olarak kullanılabilir hale getirdi ( Netscape - Netscape'te tasarlanan javascript, sunucunun düğümünden yaklaşık yirmi yıl önce) Js). Diğer tarayıcılar da bunu izledi. İnsanlar javascript kullanılan sayfalar yazıyordu, istemci tarafı komut dosyası yazma konusundaki diğer girişimler, çalışan ve çalışmayan şeyler arasında tamamen uyumsuz sayfalar anlamına gelir - veya kodun kopyalanması (burada javascript için bunu yapan {buraya dil ekleyin} bloğu tarayıcılar ve burada herkes için javascript bloğu var).

Netscape bir süre için baskın tarayıcı olduğundan javascript beklemeye alındı. Netscape'in mirası, Mozilla'nın kaynak dosyalarının dipnotlarına kaybolurken, javascript yaşıyor ve hiçbir şey yerini alamıyor.

Diğer istemci slayt komut dosyası dilleri için sorun devam etmektedir. Javascript her tarayıcıda desteklenmektedir. Biri javascript yerine python'u (örneğin) destekleyen bir tarayıcı yapmak olsaydı, web sitelerinin büyük çoğunluğunu kullanamazdı. Ayrıca, bu tarayıcı tarayıcı trafiğinden önemli bir pay alamadıysa, web tasarımcıları aynı sayfa için farklı komut dosyası dillerine sahip iki sayfa kümesi oluşturmak istemez.

Sayfada bir python komut dosyasını etkinleştiren bazı tarayıcılar için bir python komut dosyası eklentisi yapmaya çalışabiliriz ... bugün vrml'nin nasıl çalıştığına benzer. Ancak, vrml kullanan bir web sayfasını duymadıysanız ve görmedikçe, başka bir web sayfası için başka bir komut dosyası dili için kullanım bulabilir.

— Topluluk
kaynak

1

Bu, “nasıl geçti…” hakkında çok iyi bir genel bakış ve doğru cevap olarak işaretlemek istediğim kadar, “Neden bugün Javascript istemci tarafı dili kullanılıyor?” Sorusuna cevap veriyor. Python'u istemci tarafında kullanım için çok yavaş hale getirecek bir tasarım sorunu var mı? ”

— Profpatsch

VRML ... vay beni geri götürür!

— Sinirli

1

@Profpatsch, javascript ile istemci tarafı dili olmayı uygunsuz kılan hiçbir teknik tasarım sorunu yoktur - hiçbir şey kullanmadığı ve önemli bir avantaj sunmadığı sürece (muhtemelen java uygulamaları ile etkileşim dahil), hiçbir şey olmayacaktır. Sorunlar teknik değildir ve "neden javascript" tarihini anlamadığı sürece kişi neden python "cevap veremez."

2

@MichaelT: "Javascript ile istemci tarafı dili olmamasını uygunsuz hale getiren teknik bir tasarım sorunu yok" yazdınız. Python değil JS mi demek istiyorsun?

— Carl Smith

@CarlSmith Ahh evet. Benim hatam ... ve belli bir sürenin ötesinde yorumları düzenleyemiyorum. Düzeltme için teşekkürler.

4

Python'un çok yavaş olacağını düşünmüyorum. Dil hakkında, en azından JavaScript ile eşleşecek kadar hızlı çalışmasını engelleyen hiçbir şey yoktur. JavaScript'e derlenebilir, bu nedenle başka bir şey değilse tarayıcıya bir derleyici ekleyebilir ve yalnızca sayfa yükleme sürelerini artırabilirsiniz.

GÜNCELLEME: Lütfen aşağıdaki Python'u JS'ye derlemenin burada ima edilenden çok daha maliyetli olacağını tartışan aşağıdaki yorumlara bakın.

Sorun, tarayıcı satıcılarını ve W3C'yi önce Ruby veya başka bir güzel komut dosyası dili üzerinde Python'u seçmeye ikna etmeye çalışıyor, ardından sistem çağrılarına izin veremedikleri için standartlaştırılmış bir alt küme tanımlıyor ve daha sonra iyi bir şekilde uyguluyor. hala JavaScript destekliyor. Bu olmayacak, ama eğer olsaydı, hızın ciddi bir sorun olacağından şüpheliyim.

— Carl Smith
kaynak

7

İlk noktanız takip etmiyor. Her şey hemen hemen her şeye derlenebilir (makine kodu dahil), ancak bu, L dilinde yazılmış ve C dilinde derlenmiş bir programın C dilinde yazılmış eşdeğer bir program kadar hızlı olduğu anlamına gelmez.

1

CoffeeScript aslında JavaScript ile aynı temel kavramlar için farklı bir sözdizimidir ve C aslında taşınabilir bir montaj dilidir. Python ve Javascript ise oldukça farklı. Python'u doğru bir şekilde uygulamak için, sınıf modelini, operatör aşırı yüklemesini, metasınıfları vb. (Milyarlarca başka şey arasında) desteklemeniz gerekir ve bunların çoğu JavaScript ile kolay ve verimli bir şekilde eşleşmez. Bunlardan birini C veya makine koduna derlemekle aynı problem. Uzman bir JIT tek umudunuz olabilir, ancak JS'yi hedefleyen JIT derleyicilerinin henüz pratik olduğu kanıtlanmamıştır.

3

Bir sorun, JS gibi Python'u sıkıştıramayacağınız gerçeği olacaktır - tüm bu boşlukları ve satırsonlarını ortadan kaldırın ve kapsamınızı gözden geçirin! Böylece, önemli Python parçaları için daha uzun yükleme süreleri olacaksınız.

— TMN

1

@ TMN ilginç bir nokta, ancak Python'un ifadesinin bunu hafifletmek için uzun bir yol olacağını umuyor olsa da (ve evet, karakterleri değil satırları sayıyor, ancak yine de Python oldukça etkileyici bir dildir).

— Daniel B

2

@TMN Daniel B'nin söyledikleri ve ayrıca gzip farkı azaltmalı. Oh, ve Python'un bu yeni çizgi ve alanların çoğuna ihtiyacı yok. (Hepsinde olmasa bile) Birçok hatları örneğin Python, sadece ince birleştirilebilir a = something(); frobincate(a); return quuxve if condition: react()tek satır her biri. Ve n girinti seviyelerinin n * 4 aralığına değil, yalnızca n aralığa ihtiyacı vardır.

2

Bence Python'un kendi sanal makinesi var. Python ile ilgili çok fazla deneyimim yok, ancak optimize edilmemiş bir JavaScript motorunun yanı sıra performans göstermemesinin bir nedeni görmüyorum.

Bazı rastgele düşünceler:

(1) Python'u Jython kullanarak bir Java uygulaması üzerinden yerel olarak çalıştırabilirsiniz. Burada gördüğüm zor kısım, uygulamaların çok kısıtlayıcı olmasıdır, bu nedenle Jython'u erişim kısıtlamalarına uyacak şekilde değiştirmeniz gerekebilir. Örneğin, bir günlük dosyasına yazarsa, günlük kodunu kaldırmanız gerekebilir. Bir uygulamanın belirgin bir şekilde görünür olması gerekmez.

(2) Birisi bir Python-JavaScript "derleyicisi" / dönüştürücüsü oluşturabilir. Bu çok iş olurdu.

— Aaron S
kaynak

5

Someone could build a Python-to-JavaScript "compiler"/converterEh, birileri zaten yaptım .

— yannis

Brython da

— Dünya Mühendisi

Bunu asla kendim yapmak zorunda kalmadım, ama Jython kullanarak Java uygulamaları yazan insanların farkındayım. Yani aynı şey değildir Python ile tarayıcınızda Javascript değiştirmek gibi olsa.

— Martijn Pieters

Brythonen azından sayfalardaki oldukça yalıtılmış parçalar için ilginç bir şekilde hızlı çalışır (ile düşük etkileşim DOM tree).

— Profpatsch

@Profpatsch En son baktığımda, Python dilinin çok büyük bölümlerini bile uygulamıyor. Uygun olmayan şekilde, uygulanmayan özellikler arasında JavaScript'in üzerinde iyi bir şekilde uygulanması zor özellikler bulunmaktadır. PyPy yazarlarından birini yorumlamak için: Python'un önemsiz olmayan bir alt kümesini hızlı yapmak kolaydır, tam Python zorlaştığı yerdir.

1

Bu, dilin uygulanmasına bağlıdır, dilin kendisi olmak zorunda değildir. Çoğu JavaScript tercümanı, neredeyse tüm Python uygulamalarından çok daha hızlıdır.

Bu, Python dilinin JavaScript ile neredeyse aynı hızlarda kullanılamayacağı anlamına gelmez. Opal, Ruby kodunu, kapanışlara sarılmış JavaScript koduna derleyerek tarayıcıdaki neredeyse tüm Ruby dilini ve standart kütüphaneyi uygular. Opal kütüphanesini dahil etme yükünü bir kenara bırakırsak, hızı bildiğim diğer Ruby yorumlayıcılarından çok düz JavaScript'in hızına çok daha yakın.

Opal'ın bir Python muadili olup olmadığını bilmiyorum, ancak böyle bir proje muhtemelen sorunuzun cevabının "hayır" olduğu anlamına gelir. JavaScript'in "web için bir montaj dili" olarak artan kullanımı ile, özellikle mobil hesaplama gücü arttıkça ve bir dilin ek yükü olduğu için, diğer diller için bir platform olarak daha fazla kullanılacağı beni şaşırtmayacaktır. JavaScript'te uygulanan önemsiz hale gelir.

EDIT: İşte JavaScript için derleyen / çalışan tarayıcı için Python uygulamalarının bir listesi.

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

Ve ilgileniyorsanız, gerçekten sevdiğim Opal'a göz atabilirsiniz.

http://opalrb.org/

Tarayıcıların ayrı ayrı tercümanlar için destekle geleceğinden şüphelendiğimden, bu tür derleyiciler muhtemelen JavaScript dışındaki dilleri kullanma açısından geleceğin yolu. Şimdi bile, çoğu alanda karşılaştırılabilir performans elde edeceksiniz. Bu benim görüşüm, ancak bunu aklınızda bulundurun.

— Ravenstine
kaynak

0

Bu soruyu sorduğunuzda bile, javascript'te bugün web sayfalarında kullanılabilecek bir dizi python uygulaması zaten vardı.

Göz at http://www.skulpt.org/ veya http://www.brython.info/ başlayanlar için.

Performans çok kötü görünmüyor, ancak bunları kendiniz test etmeli ve öğrenmelisiniz.

— fabspro
kaynak

-4

Python sunucuda çalışan bir "konsol" dilidir

Javascript, istemcide çalışan bir "tarayıcı" dildir

Bu nedenle, doğrudan rekabet etmiyorlar

... elbette node.js ve muhtemelen python tarayıcı eklentileri var, ancak daha sonra belirli bir uygulamanın performansıyla ilgili bir soru.

Üstelik, birçok uygulama için, bir tür kapsamlı hesaplama yapmanız ve CPU döngülerini sıkmanız dışında, python iyi bir iş çıkarır.

Son bir not olarak, python ve javascript birçok benzerlik paylaşıyor. Dinamik yapıları nedeniyle, her ikisi de çalışma zamanında yorumlanmalıdır ve statik yazılan diller kadar güçlü bir şekilde derlenemezler. Bu nedenle, elde edilebilir performanslarının benzer olacağını varsayıyorum.

— dagnelies
kaynak

2

Sunucu tarafı javascript '94 oldu. jscbir konsol olarak javascript ile çalışmanıza izin verir python, bir konsola yazdıklarında alacağınızla aynıdır .

@MichaelT: Tamam, cevabımı buna göre düzenledim

— dagnelies

2

Ayrıca Python masaüstü uygulamaları yazabilirsiniz .... Yaptığınız ayrım için gerçek bir neden görmüyorum.

— Chris Travers

Ayrıca, 3B modelleme aracı Blender, kullanıcı arayüzünden ağ oluşturmaya kadar her şey için Python'u kullanıyor. Bu performans açısından rekabetçi değilse, nedir?

— Andrew Gray

@Chris: ayrım, javascript'in öncelikle bir tarayıcı teknolojisi, python ise esas olarak bir masaüstü / konsol teknolojisidir. Demek istediğim, her ikisini karşılaştırmanın pek bir anlamı yok çünkü tamamen farklı amaçlara hizmet ediyorlardı.

— dagnelies