Seite 2 von 2
Re: PyPy.js
Verfasst: Freitag 12. Juni 2015, 18:47
von Sirius3
@jens: die Dateien werden doch sowieso standardmäßig gzipt. Damit haben sie fast die gleiche Größe.
Re: PyPy.js
Verfasst: Samstag 13. Juni 2015, 00:23
von jens
Jain.
Selbst wenn gzip vom Server zum Zuge kommt, ist lzma effizienter.
Ich habe Tests gemacht, dabei
pypy.vm.js und
pypy.vm.js.mem genommen. Das sind die beiden "init" Dateien, die 19,2MB groß sind.
Mit gzip und der höchsten Kompressionsstufe bekommt man beide Dateien auf 3,83 MB gequetscht.
Wenn ich lzma mit dem preset 3 bzw. 4 wähle, komme ich auf ähnliche Kompressionszeiten, aber kleineren Dateien: zusammen 2,6MB
Nicht die Welt, aber immerhin 1,23 MB zusätzlich eingespart.
Wenn ich dann noch die lzma preset 9 wähle, sind es statt 2,6MB nur 2,44 MB... Also 1,39 MB weniger... Allerdings ist hier dann auch die Kompressionszeit bei mehreren Sekunden.
Ich vermute auch, das gzip bei einer Standard-Server-Konfiguration nicht mit der höchsten Kompressionsstufe betrieben wird.
Wäre IMHO gut, wenn Server und Browser mal lzma unterstützen würden. Den Standard gibt es nun auch schon seid zig Jahren. In Python gibt es den auch erst seid v3.3...
Das dekomprimieren per JavaScript mit
https://github.com/nmrugg/LZMA-JS dauert natürlich auch ein paar Sekunden. Dabei habe ich lzma preset=3 gewählt.
Ist natürlich die Frage, ab welcher Download-Geschwindigkeit das ein oder andere besser ist :K
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 07:48
von jens
Nochmal eine Rückmeldung...
Wie sich gezeigt hat, ist LZMA-JS doch zu langsam.
Auf meinem Arbeitsrechner mit I7-4790K ist das dekomprimieren zwar in 3-4Sek fertig. Aber auf einen älteren Rechner braucht es um die 13Sek. Siehe:
https://github.com/pypyjs/pypyjs.github ... -111549828
Ich hab einen recht umfangreichen benchmark für Packer gefunden:
https://quixdb.github.io/squash-benchmark/
Dort kann man neben einer Fetten Xeon E3-1225 Maschine auch den RaspberryPi2 und Beagleboard-XM nutzten.
Interessant sind IMHO die Packer:
- doboz
- lzham
- zlib:deflat
- lzo
Leider gibt es aber "doboz" und "lzham" nicht als JavaScript implementierung.
Von LZO hab ich nur "miniLZO" in JavaScript gefunden:
https://github.com/abraidwood/minilzo-js
Deswegen hab ich mit mal
zlib:deflat angesehen:
https://github.com/imaya/zlib.js
Eine Beispiel hab ich fertig:
https://github.com/pypyjs/pypyjs.github ... 87f378e9fb
Im Vergleich zu
lzg ist
zlib:deflat super schnell! Auf dem Rechner, des für lzg rund 13Sek gebraucht hat, ist die
zlib:deflat nach 204ms und 157ms fertig! (Für pypy.vm.js_level9.deflate und pypy.vm.js.mem_level9.deflate
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 12:18
von BlackJack
@jens: Der zlib:deflate-Algorithmus ist doch genau der den `gzip` verwendet, also etwas das sowieso jeder normale Browser schon ohne irgendwelche zusätzlichen JavaScript-Geschichten für Dateien unterstützt. Da spart man sich vielleicht ein paar Bytes für den GZIP-Header, aber dafür würde ich mir doch keine JavaScript-Bibliothek zusätzlich ins Boot holen.
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 13:12
von jens
Da hast du recht. Wenn es denn auch aktiv ist. Dann auch die Frage, welcher Kompressions-Level ist Standard?
Es ist auch nicht die erste Wahl. Aber es gibt halt nicht so viele Packer in JavaScript.
Im Idealfall wäre es ein Packer der gut komprimiert (ruhig auch dafür lange braucht) aber schnell im Browser de-komprimiert.
Wobei die Frage ist, wie schnell ist ausreichend?!?
Ist aber kompliziert: Weil es von der Internet-Geschwindigkeit und dem verwendeten System abhängt:
Bsp.:
- Langsamer Rechner an 100MBit Leitung
- Schneller Rechner an 768 DSL
Am vernünftigsten erscheint es mit, sich an den Langsamen Rechner zu orientieren. Deswegen auch
https://quixdb.github.io/squash-benchmark/ so eingestellt:
- dataset ->"Tarred source code of Samba 2-2.3"
- platform -> "raspberry-pi-2"
Wenn man die unbedeutenden Packer weg lässt kommt das dabei raus:
Also wie schon geschrieben, die interessanten:
- doboz: tick besser als zlib, aber viel schneller
- lzham: komprimiert deutlich besser, schneller als lzma, aber Geschwindigkeit ausreichend?!?
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 13:25
von Sirius3
@jens: zlib ist immer viel schneller, weil es schon im Browser integriert ist. Bleibt noch lzham oder brotli, weil sie viel besser komprimieren, aber dann auch um Faktoren langsamer dekomprimieren.
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 13:52
von jens
Sirius3 hat geschrieben:@jens: zlib ist immer viel schneller, weil es schon im Browser integriert ist. Bleibt noch lzham oder brotli, weil sie viel besser komprimieren, aber dann auch um Faktoren langsamer dekomprimieren.
Natürlich. Aber ich hab halt erstmal nur zlib als JavaScript Implementation...
Auf jeden Fall ist das schon viel mal besser als nicht komprimiert:
6.6M pypy.vm.js.mem
1.9M pypy.vm.js.mem.gz
1.93M pypy.vm.js.mem_level9.deflate
2.6M pypy.vm.js.mem.lz4
2.0M pypy.vm.js.mem.lz4.gz
und die
pypy.vm.js ist noch größer:
12.68 MB pypy.vm.js
1.88 MB pypy.vm.js_level9.deflate
Macht schon einen Unterschied statt run
20 MB nur
3,8 MB ziehen zu müßen. Da machen die rund
350ms entpackzeit nichts aus.
Bzw. wie schnell muß die Leitung sein, das die zusätzlichen 350ms das ganze "verlangsamen"?!?
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 14:21
von BlackJack
@jens: Was heisst Du hast nur `zlib` als JavaScript-Implementation? Der Browser hat deflate schon in C oder C++ implementiert und benutzt das zum entpacken wenn die Datei entsprechend gekennzeichnet `gzip`-komprimiert ausgeliefert wird. Darum sehe ich den Sinn von einem `zlib` in JavaScript in dieser Situation einfach nicht.
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 14:33
von snafu
jens hat geschrieben:Macht schon einen Unterschied statt run 20 MB nur 3,8 MB ziehen zu müßen. Da machen die rund 350ms entpackzeit nichts aus.
Bzw. wie schnell muß die Leitung sein, das die zusätzlichen 350ms das ganze "verlangsamen"?!?
Also 0,3 Sekunden können in diesem Zusammenhang wohl vernachlässigt werden.
Re: PyPy.js
Verfasst: Dienstag 16. Juni 2015, 14:50
von jens
BlackJack hat geschrieben:@jens: Was heisst Du hast nur `zlib` als JavaScript-Implementation? Der Browser hat deflate schon in C oder C++ implementiert und benutzt das zum entpacken wenn die Datei entsprechend gekennzeichnet `gzip`-komprimiert ausgeliefert wird. Darum sehe ich den Sinn von einem `zlib` in JavaScript in dieser Situation einfach nicht.
Schon klar... Wenn der Server auch wirklich komprimiert. Aber das war das Ursprüngliche Problem von
https://github.com/pypyjs/pypyjs.github.io/issues/4
Die Datei
pypy.vm.js.mem endet auf
.mem und in der Standarteinstellung vom github.io hat man deswegen kein caching und keine Komprimierung. Deswegen ist z.Z. die Seiten
http://pypyjs.org/ ziemlich langsam. Insbesondere der Editor
http://pypyjs.org/editor.html
Nun kann man den Server wechseln, damit man es selbst unter Kontrolle hat oder die Datei Endung auf irgendwas "normales" ändern, damit sie per
application/octet-stream + caching header + gzip Kompression ausgeliefert wird...
Tritte Möglichkeit: einen CDN Service nutzten, den man entsprechend einstellen kann...
Vierte Möglichkeit: Dateien manuell komprimieren und im Browser per JS entpacken. Theoretisch wäre das die flexibelste Möglichkeit. Wobei auch hier eine Dateiendung gut wäre, die mit "
application/octet-stream + caching header + gzip Kompression" ausgeliefert wird...
Re: PyPy.js
Verfasst: Donnerstag 18. Juni 2015, 17:18
von jens
Vielleicht wird es durch "Webassembly" alles leichter:
...Webassembly (Wasm): ein portables, auf geringe Größe und kurze Ladezeiten optimiertes Binärformat samt Ausführungsmodell - ein Bytecode für das Web also.
->
http://www.golem.de/news/webassembly-br ... 14745.html
Wird auch schon diskutiert:
https://github.com/pypyjs/pypyjs/issues/145
btw. Mit
https://github.com/pypyjs/pypyjs.github ... 237a16a5e4 hab ich meinen "Packer" test code ein wenig aufgeräumt und einen richtigen Benchmark gemacht, der Markdown produziert.
pypy.vm.js + pypy.vm.js.mem mit allen Levels/Presets von zlib, bzip2 und lzma ist hier:
https://gist.github.com/jedie/d650de636711aa786235
Eine andere Idee, ist noch das caching im
localStorage, siehe:
https://github.com/pypyjs/pypyjs.github.io/issues/8
Dabei wäre es vom Vorteil, wenn man vom Server komprimierte Dateien, statt http-gzip/deflate bekommt, weil man sie dann nicht per JS komprimieren müßte...
Eine weitere Idee bzw. Frage: Lohnt es sich die einzelnen Requests zusammen zu fassen? ->
https://github.com/pypyjs/pypyjs.github.io/issues/7
Nicht nur pypy.vm.js + pypy.vm.js.mem sondern auch die späteren Requests die entstehen, wenn man python Module importiert... Denn z.B. ein "import platform" löst z.Z. 58 GET Requests aus
Sieht dann so aus:

Re: PyPy.js
Verfasst: Montag 22. Juni 2015, 09:11
von Kebap
jens hat geschrieben:Vielleicht wird es durch "Webassembly" alles leichter. Wird auch schon diskutiert
Ich hab auch davon gehört. Klingt so, als wäre der Quellcode dann nicht mehr im Browser einsehbar? Das fände ich eher un-pythonisch ...
http://blog.fefe.de/?ts=ab7c7bf5 hat geschrieben:Ich weiß ja nicht, wie euch das geht, aber ich hoffe inständig, dass "WebAssembly" floppt. So doll wie möglich am besten. Verbrannte Erde wäre gut. So übel, am besten, dass nie wieder jemand was in die Richtung probiert.
ENDLICH sind wir weg von diesem Flash-Binärkack und von Binaries für irgendwelche speziellen Plattformen und haben Skriptsprachen für eine gemeinsame Plattform. Endlich kann man einfach Ctrl-U machen und sich angucken, was da passiert. Kaputte Skripte zur Not selber debuggen. Selbstgehackte DRM im Web ist endlich weg (abgesehen von diesem Chrome-Netflix-Zeugs).
Und was machen diese Schwachmaten da? Erfinden ein neues Binärformat fürs Web. Und sagen explizit an, dass das ein Compiler-Target sein soll. JA SUPER! Ich sage gleich mal an, dass es eine Industrie geben wird, die auf Basis davon DRM baut, die "Obfuscation"-Technologien verkaufen wird, und wir werden eine neue dunke Ära für geschlossenes Web einleuten. Und das alles so völlig ohne Not! Und dann werden wir wieder "works best in Internet Explorer" haben. Eine Frage der Zeit, bis Microsoft oder Apple spezielle proprietäre APIs für ihre "Web-Binaries" exportieren. DirectX für WebAssembly! Und am Ende haben wir dann ein verkapptes .NET für Arme im Browser. Hint: Hatten wir schon. Hieß Silverlight. Ist gefloppt.
Re: PyPy.js
Verfasst: Montag 22. Juni 2015, 09:25
von jens
Kebap hat geschrieben:Ich hab auch davon gehört. Klingt so, als wäre der Quellcode dann nicht mehr im Browser einsehbar? Das fände ich eher un-pythonisch ...
Was PyPy.js anbelangt, bleibt es ja dabei, das Python Skripte ausgeführt werden. In diesem Fall ist es nur Einfach einen Python Interpreter in den Browser zu laden. Das ist alles...
Ich bin mir allerdings noch nicht ganz sicher, ob wasm es wirklich eine starke Beschleunigung sein wird. Denn die größe, des PyPy-Interpreter wird sich vermutlich nicht all zu stark ändern, wenn beide Varianten komprimiert zum Client kommen werden...
Aber natürlich fällt einiges an Umwandlung weg.
Was das ablösen von JavaScript im allgemeinen anbelangt: Las uns das lieber im separaten Thread diskutieren!
->
http://www.python-forum.de/viewtopic.php?f=5&t=36532
Re: PyPy.js
Verfasst: Mittwoch 1. Juli 2015, 09:13
von jens
Kurzer Zwischenstand...
Hab noch
https://github.com/kripken/emscripten/issues/3589 eröffnet und dort generell das Kompressions-Thema vorgestellt. Dort sind quasi die aktuelle Erkenntnisse zum Thema gesammelt.
Mit
https://github.com/jedie/pypyjs.github. ... a9dd641cdd läuft nun die erste Implementierung für
https://github.com/pypyjs/pypyjs.github.io/issues/7
Also das zusammenfassen von
.py Dateien in einem Archiv.
z.Z. ist es so, das bei einem import jeweils eine .py Datei nacheinander per GET gezogen werden. Wenn man z.B. ein
import platform macht, zieht das 58 GET Requests nach. (Siehe Bild oben, bei
http://www.python-forum.de/viewtopic.ph ... 68#p278668 )
Ein "import platform" kann man aktuell direkt vergleichen:
Allerdings geht bei meiner Variante [1] nur ein "import platform", weil z.Z. nur die Datei "platform.zip" hoch geladen ist:
https://github.com/jedie/pypyjs.github. ... s/download
Meine Variante [1] kann man eigentlich zwei Sachen sehen:
Nun frage ich mich allerdings, welchen Unterschied es wohl machen wird, wenn man statt eine "platform.zip" eine "platform.json" erzeugen würde?!?
In diesem Fall würde man nicht die Server/Browser gzip Kompression umgehen (sofern eingeschaltet)... Das Parsen vom .json würde der Browser auch direkt unterstützen...
Re: PyPy.js
Verfasst: Mittwoch 1. Juli 2015, 10:38
von jens
jens hat geschrieben:Nun frage ich mich allerdings, welchen Unterschied es wohl machen wird, wenn man statt eine "platform.zip" eine "platform.json" erzeugen würde?!?
In diesem Fall würde man nicht die Server/Browser gzip Kompression umgehen (sofern eingeschaltet)... Das Parsen vom .json würde der Browser auch direkt unterstützen...
Wenn ich so näher darüber nachdenke...
Mit JSON würde man die Dateigröße ein wenig Aufblasen. Gerade dann, wenn ich Binärdatei
pypy.vm.js.mem mit base64 einbinden wollen würde...
Würde es dennoch unterm Strich schneller sein, als die aktuelle
.zip Lösung, die komplett per JavaScript geparst/dekomprimiert wird?
Man könnte auch noch überlegen, was anderes als .json zu nutzten. z.B.: binär formate wie:
Dann würde man allerdings wieder im Browser selbst parsen müssen.
Außerdem wieder die Frage, welche Dateiendung out-of-the-box mit gzip vom server komprimiert werden würde...
Ich denke als erstes, werde ich einfach mal eine einfache .json Version bauen. Denn das dürfte auch am schnellsten machbar sein

Re: PyPy.js
Verfasst: Mittwoch 1. Juli 2015, 21:47
von jens
Hab mit
https://github.com/jedie/pypyjs.github. ... 0253b16255 eine plain-.json test fertig.
Einfach auf den "run" button klicken, zum Vergleich auf diesen beiden Seiten:
Eigentlich sind hier zwei Dinge unterschiedlich:
* Bei der .zip Variante wird in JavaScript geparst und dekomprimiert
* Beim .json passiert parsen und dekomprimieren komplett im Browser
Die .zip Variante ist allerdings um einiges schneller

:
Mit leerem browser cache:
- .zip -> Run in 1.7sec.
- .json -> Run in 5.5sec.
Mit vollem Browser cache (dazu einfach nochmal auf die "run" Schaltfläche klicken:
- .zip -> Run in ~250ms
- .json -> Run in ~2.5sec.
Mit diesem Ergebnis hätte ich nicht gerechnet. Gut das "platform.json" ist 1,3MB groß. Aber so langsam sollte es nicht sein, oder?
Vielleicht hab ich, wider besseren JS Wissens, eine Bremse eingebaut?
Das Komprimieren ist zwar schlechter, aber ganz ok:
Original 'platform.json': ist 1.3MB groß
Mit python komprimierte .zip: 328.7KB
Von github gesendete Daten: 351,5 KB (In Firebug abgelesen)
Re: PyPy.js
Verfasst: Donnerstag 2. Juli 2015, 01:01
von Daikoku
Sorry, aber ich verstehe erstens die ganze Euphorie hier nicht, und zweitens was soll das Ziel des Projektes sein ?
Eine Console für Python in einen Browser zur Verfügung zu stellen und ein paar Python-Berechnungen in einem Browser zu rendern ?
Oder reden wir hier endlich einmal über eine zeitgemäße Front-End-Entwicklung mit Python im Browser mit all seinen Möglichkeiten, welche ich heute schon mit AngularJS2 bereits umsetzen kann ?
Re: PyPy.js
Verfasst: Donnerstag 2. Juli 2015, 06:32
von jens
die ganze Euphorie
Wo soll die sein?!?
Ist erstmal nur ein Spaß Projekt.
Der Hintergedanken ist natürlich schon, das man es auch praktisch nutzten kann. Aber ob das wirklich jemals was wird, ist fraglich...
Re: PyPy.js
Verfasst: Donnerstag 2. Juli 2015, 12:12
von jens
Daikoku hat geschrieben:...was soll das Ziel des Projektes sein ?
Eine Console für Python in einen Browser zur Verfügung zu stellen und ein paar Python-Berechnungen in einem Browser zu rendern ?
Oder reden wir hier endlich einmal über eine zeitgemäße Front-End-Entwicklung mit Python im Browser mit all seinen Möglichkeiten, welche ich heute schon mit AngularJS2 bereits umsetzen kann ?
Das ist natürlich eine gute Frage. Wenn man es mal ernster sieht, als "ein Spaß Projekt"...
Ich kann dazu das schon erwähnte Video von der PyCon empfehlen:
https://www.youtube.com/watch?v=PiBfOFqDIAI
Das erster Ziel, wäre es, erstmal eine praktischere Nutzbarkeit zu schaffen. z.Z. sind die Ladezeiten und damit die "Initialisierungs-Zeit" einfach zu lang.
Wie weiter oben schon geschrieben: Es müssen erst mal 20 MB Daten geladen werden. Gut, alleine mit dem Packen, bekommt man die auf rund 4MB...
Dann ziehen Python Modul Importe jede Menge Requests nach.
Diese Beiden Punkte untersuche ich ja gerade, mit:
Evtl. bring das schon erwähnte WebAssembly eine ganze Menge, siehe:
https://github.com/pypyjs/pypyjs/issues/145
Aber gehen wir mal davon aus, das Lade-/Init-Zeiten kein Problem wären:
Natürlich kannst du erstmal ziemlich das selbe in JavaScript machen. Von daher ist das alles Sinnlos...
Aber wäre es nicht richtig Spannend eine "Gescheite" Sprache wie Python zu haben?
Trotz allem Fortschritt mit JavaScript, finde ich, das Python dennoch einige Vorteile hat.
Re: PyPy.js
Verfasst: Dienstag 3. November 2015, 16:54
von jens
Talk Python To Me Podcast -
Episode #32: PyPy.js - PyPy Python in Your Browser
Published Tues, Nov 3, 2015, recorded Wed, Sep 30, 2015.
->
http://talkpython.fm/episodes/show/32/p ... ur-browser