1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Copperlicht - 3D…

Wer Java mit javascript verwechselt

  1. Thema

Neues Thema


  1. Wer Java mit javascript verwechselt

    Autor: javajim 10.02.10 - 10:00

    ist reif für die Insel Java. JavaScript im Browser ist eine wahre Freude an Tempo im Gegensatz zu Applets. Es gibt einen netten Emulator für mobile Websites, wo ein Handy simuliert wird. Heißt mobilokchecker oder so. Der IE hat 200 MB Ram eingenommen, bevor kapituliert hat. Der Firefox war glaube ich bei 500 und hat kapituliert. In Opera lief das Teil dann halbwegs flüssig.

  2. Re: Wer Java mit javascript verwechselt

    Autor: Gemawoandershin 10.02.10 - 11:45

    Java Applets lassen sich im übrigen auch auf performance programmieren ;)

    Leider haben die meisten keine Lust dazu.

  3. Re: Wer Java mit javascript verwechselt

    Autor: X99 10.02.10 - 15:29

    Das ist so die Universalausrede. Angeblich kann kein einziger auf der Welt richtig Java programmieren, da ja alle Programme davon langsam sind.

  4. Re: Wer Java mit javascript verwechselt

    Autor: Gemawoandershin 10.02.10 - 16:08

    Mit "alle" meinst Du welche Anwendungen?

  5. Re: Wer Java mit javascript verwechselt

    Autor: Bleibemahier 10.02.10 - 20:14

    Mal andersrum gefragt:
    Welche (bis zum jetzigen Zeitpunkt) real existierende, in Java geschriebene Anwendung läuft denn flüssig?

  6. Re: Wer Java mit javascript verwechselt

    Autor: It's me, Luigi 10.02.10 - 21:39

    Äh hallo? JSPs sind auch Java und wenn du dich mal im Banken und Versicherungsumfeld umschaust läuft das dort auch. Ohne Performanceprobleme.

  7. Re: Wer Java mit javascript verwechselt

    Autor: ThoWoi 11.02.10 - 09:33

    Erzählt doch nicht soviel Unsinn. Ich habe mal vor Jahren einen C&C 1 Klon als Java Applet geschrieben, der lief damals auf meinem alten System schon richtig flüssig. Es gibt eine Menge Firmen die ihre gesamte Software mit Java entwickeln lassen.

  8. Re: Wer Java mit javascript verwechselt

    Autor: iKrise 11.02.10 - 20:36

    Kein Wunder, dass wir ne Bankenkrise haben.. :-D

    Nee, Spaß beiseite. Aber Javaanwendungen sind schon langsamer als C++ oder ähnliches (Vorausgesetzt natürlich bei gleichem Optimierungsgrad des Quellcodes)

  9. Re: Wer Java mit javascript verwechselt

    Autor: krymel2k10 12.02.10 - 11:29

    Super, viel kombiniertes Halbwissen.

    Die JVM ist die wohl am weitesten entwickelte Stack-basierte VM. Sie optimiert einzigartig und ist in vielen Fällen schneller als ein optimiertes C++-Kompilat. Sei es compiled by Intel, MS, GCC, whatever.

    Die Oberfläche von Java-Anwendungen kann langsam sein, wenn man ein GUI-Toolkit wie z.B. Swing oder das darunter liegende AWT verwendet. Doch auch hier hat sich in den letzten Jahren viel getan.

    Der moderne Ansatz ist, bei Oberflächen auf Toolkits wie SWT zu setzen. Oder QTJambi, was leider nicht mehr großartig entiwckelt wird. Das gesamte Eclipse-Ökosystem basiert darauf und nahezu alle modernen Architekturen haben eine auf Eclipse-basierende Entwicklungsumgebung.

    Das Problem bei Swing / AWT in der Oberflächen-Renderinggeschwindigkeit liegt darin, das pro Betriebsystem eine unterschiedliche Grafik-API angebunden werden muss. Die Wahl der ursprünglichen JVM-Entwickler war, die am tiefsten gelegene API zu wählen. Also API's die Linien, Rechtecke etc. rendern. Und alle Widgets (Buttons, Panels, etc.) selbst zu rendern. So entstehen viele Schichten von Calls (20-Schichtcalls um einen Button zu renden) welche in der JVM verarbeitet werden und am Ende an die native API des Systems zum rendern weitergereicht werden. Das ist natürlich inperformant. Moderne API's wie SWT stellen eine Java-API-bridge dar. Bei SWT wird eine Bridge zum GTK-Toolkit geschaffen, welches nativ ebenfalls auf verschiedenen Systemen portiert wurde. So wird bei SWT beim Rendern eines Buttons direkt die native Klasse zum rendern des Buttons aufgerufen und der Mehrschicht-Call vermieden.

    Bei Applets sieht die Sache wieder anders aus. Hier wird standardmäßig AWT verwendet. Es ist aber auch möglich SWT-Libraries per Applet auszuliefern. Das macht nur niemand, weil die nativen Libs mit ausgeliefert werden müssten. Und da gibts dann neben Security-Policy-Problemen auch Probleme mit der Downloadgröße...

    Also im Web entweder Javascript verwenden. Oder als Notnagel Flash (auch eine JVM-ähnliche VM...).

    Javascript (EcmaScript!) ist die Zukunftsperspektive. Demnächst kommen mit Tamarin, V8, TraceMonkey etc. die nächsten Generationen von Javascript-VM's. Teilweise Stack - teilweise Memory-basiert.

    Es gibt keinen Grund warum Javascript in der Ausführung nicht genauso schnell sein kann wie Java, Smalltalk, oder nativ kompiliertes C++...

  10. Re: Wer Java mit javascript verwechselt

    Autor: MartinF 14.02.10 - 13:20

    krymel2k10 schrieb:
    --------------------------------------------------------------------------------
    > Die JVM ... ist in vielen Fällen schneller als ein
    > optimiertes C++-Kompilat.
    Quelle / Beispiel?

    > Es gibt keinen Grund warum Javascript in der Ausführung nicht genauso
    > schnell sein kann wie ... nativ kompiliertes C++
    Doch: eine VM verbraucht zusätzliche Ressourcen.

  11. Re: Wer Java mit javascript verwechselt

    Autor: mi san trob 17.02.10 - 23:57

    >Quelle / Beispiel?
    http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance

    Und lies dir bitte den ganzen abschnitt durch (aber das machst du eh nicht)

    >Doch: eine VM verbraucht zusätzliche Ressourcen.
    http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Resource_management

    Ach, du bist mein held. Java nimmt dir durch sein pointer management (u.a.gb zeugs) sehr viel ab. Ziel in der software entwicklung sollte es sein, schnell zu entwickeln, überall laufen, sicher und performant. Und weil deine 3d games in c++ sind... ach, ich hab keinen bock

  12. Re: Wer Java mit javascript verwechselt

    Autor: MartinF 23.02.10 - 01:03

    mi san trob schrieb:
    --------------------------------------------------------------------------------
    > >Quelle / Beispiel?
    > en.wikipedia.org#Performance
    >
    > Und lies dir bitte den ganzen abschnitt durch (aber das machst du eh
    > nicht)
    Hab dir den Gefallen getan, damit du nicht noch mehr jammerst ;)
    War jedenfalls verschwendete Zeit; keine konkreten Zahlen.

    > - Java could potentially be faster than C++
    > - Java garbage collection may have better cache coherence
    > - Run-time compilation can potentially use additional information available at run-time to optimise code more effectively
    Nach hieb- und stichfesten Fakten hört sich das für mich nicht an. Aber es wird noch besser:

    > Static compilers can be given hints, using command-line switches or pragmas, ..., but these choices may be wrong for where and when the code is actually run.
    Java ist also deswegen besser weil C++-Programmierer nicht mit dem Compiler umgehen können ...

    > JIT ... allows optimization using current run-time measurements. This adds an additional runtime overhead as code is optimised, but is theoretically capable of increasing performance in processes that run for a very long time.
    Sows ähnliches gibts für C++ auch, nennt sich Profile-Guided Optimization und verschwendet nicht die Zeit der Endkunden.

    > Java often outperforms C++ in operations such as heap allocation and file I/O while C++ often outperforms Java in arithmetic and trigonometric operations.
    Die erste konkrete Aussage; wäre die doch bloß von dir gekommen ...
    Der Grund für den Performanceunterschied? Im C++ Benchmarkcode wurden weder Memory-mapped File I/O noch Allocaters für die Heap-Objekte verwenden.

    > ... when C++ code is tweaked to be algorithmically comparable, overall C++ runs about twice as fast as Java.
    Die nummerische Überlegenheit dürfte wohl keiner mehr abstreiten können.

    > C++ allows passing objects by value to functions, which can cause significant overhead in the case that much memory must be copied or inefficient copy constructors must be called.
    ByValue ist eine Option (die es bei Java für Objekte erst gar nicht gibt) und keine Pflicht. Auch hier liegt es also nicht an der Sprach sondern am Programmierer, wie performant das Programm am Schluss ist.

    > >Doch: eine VM verbraucht zusätzliche Ressourcen.
    > en.wikipedia.org#Resource_management
    Der Overhead einer VM ist also - wie ich erwähnte - nicht vernachlässigbar.

    > Ach, du bist mein held.
    Das hab ich nicht nötig =)

    > Java nimmt dir durch sein pointer management (u.a.gb zeugs) sehr viel ab.
    Hättest die Links wohl erst mal selber lesen sollen :P
    > The C++ standard permits garbage collection, but does not require it.

    Ein GC muss nicht immer ein Segen sein:
    http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Disadvantages

    > Ziel in der software entwicklung sollte es
    > sein, schnell zu entwickeln, überall laufen, sicher und performant.
    Off Topic; hier geht es nicht um den Prozess der Softwareentwicklung sondern um Java/C++ bzw. deren VM/Compiler.

    > Und weil deine 3d games in c++ sind...
    Ich werde meine Treiber, Firmwares und Anwendungen (und eventuell mal wieder ein Spiel :P) weiterhin in C++ schreiben.

    > ach, ich hab keinen bock
    Trotzdem danke für die Herausforderung =)

    "The idea behind C++ is not to prevent bad programmers from writing bad code, but to make it possible for the reasonable ones to write superior code."

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Technische*r Projektleiter*in (w/m/d)
    Hensoldt, Ulm
  2. Anwendungsbetreuerin / Anwendungsbetreuer (w/m/d) SAP-Benutzer- und Zugriffsverwaltung
    Berliner Stadtreinigungsbetriebe (BSR), Berlin
  3. Senior Manager Solutions & Analytics (w/m/d)
    HUK-COBURG Versicherungsgruppe, Coburg
  4. Senior Requirements Engineer (m/w/d)
    Ärztekasse Genossenschaft, Urdorf (Schweiz)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. u. a. Gigabyte B550 Gaming Mainboard für 107,90€ statt 145,90€
  2. (bis 17.01.2024)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Dune & Children of Dune: Zwei Miniserien für die ersten drei Wüstenplanet-Romane
Dune & Children of Dune
Zwei Miniserien für die ersten drei Wüstenplanet-Romane

Vor 20 Jahren gab es bereits eine Fortsetzung von Dune. Wer nicht auf Villeneuves nächste Filme warten will, kann jetzt zum Wüstenplaneten aufbrechen.
Von Peter Osteried

  1. Battlestar Galactica Der Reboot hat einen neuen Showrunner
  2. Serienschöpfer MacFarlane "The Orville ist nicht tot"
  3. Titel für erstes Spin-off bekannt Dreharbeiten für Doctor-Who-Ableger starten im März

Softwareentwicklung: Scrum-Abenteuer auf der grünen Wiese
Softwareentwicklung
Scrum-Abenteuer auf der grünen Wiese

Wie wir anderthalb Jahre lang im Greenfield-Projekt Scrum versuchten, über Bord warfen und völlig deformierten - um dann zu erkennen, dass wir es lebten.
Ein Erfahrungsbericht von Rene Koch

  1. Scrum of Scrums Ein leichtgewichtiges agiles Framework

Hewlett Packard Enterprise: Was die Übernahme von Juniper Networks durch HPE bedeutet
Hewlett Packard Enterprise
Was die Übernahme von Juniper Networks durch HPE bedeutet

Juniper-Vorstandschef Rami Rahim wird den gemeinsamen Bereich HPE-Network leiten. Dazu gehört auch Aruba Networks.
Von Achim Sawall

  1. Hewlett Packard Enterprise HPE will offenbar Juniper Networks kaufen