schnelles java prog
-
volkard schrieb:
generpft schrieb:
Wen interessieren irgendwelche unrealistischen Benachmarks. Wir haben z.B. 2 kleinere gekaufte Programme in der Firma die umgefähr das gleiche machen, auf DBs zugreifen und schrieben. Das eine in Java braucht sicher 30 Sekunden zum starten und ist in der Bedienung lahm (speichern von ein paar einfachen änderungen braucht ca. 5 Sek.). Das andere ist wahrscheinlich in C++ geschrieben, startet in 1-2 Sekunden, speichern brauch praktisch keine Zeit, klick und fertig. Und das schnellere nicht Java Programm hat auch noch mehr DB einträge.
das liegt aber dann wohl nicht an der sprache java, sondern daran, daß java inzwischen ausschließlich von untalentierten programmierern benutzt wird.
das ist wohl wirklich 50% vom grund.
aber das starten dauert nunmal auch seine zeit, wenn alles zusammen compiliert/link wird, zumindestens wenn es in keinem cache ist. zudem muss die java VM vorher auch noch starten.
was ich viel schlimmer finde ist dass selbst fuer die winzigsten programme die VM sich gleich nen ordentlichen batzen speicher zieht
wir hatten in der arbeit ein tool zum remote editieren, das hatte 10MB gezogen und war ratz fatz gestartet, die tools programmer haben es auf c# umgestellt, seitdem kann ich im task manager die MB-anzeige vom programm als start-progressbar benutzen, bis es auf 200MB ist
ich weiss nicht, ob das an der sprache oder den programmierern liegt, aber ich wuenschte das alte toll waere noch kompatible.
-
Ich schreibe selbst gerade ein JAVA-Programm fürs Handy. Was mich daran stört ist das RAD.
Ich verwende Netbeans und das hat nicht auf anhieb funktioniert.
Weiters muss man alles ohne GUI erstellen. Sogar einfache Buttons.
Was ich aber genial finde sind Frameworks wie z.B. LWUIT.
Sowas vermisse ich beim NET Compact Framework noch.
Vorteil ist aber das es auf allen Handys gleich funktioniert die mit NET arbeiten.
Bei Java ist das leider nicht so und einfachste Dinge wie Webservice (JS 172) gibt es nicht überall bzw. sind nicht vollständig implementiert.
Auch wenn man sagt das Java Plattformübergreifend ist stimmt es in diesem Bereich (J2ME) nicht.
Deshlab werde ich auch bei NET COMPACT bleiben.
-
haette java einen richtigen garbage collector würde sich jedes programm selbst löschen!
-
PRIEST schrieb:
haette java einen richtigen garbage collector würde sich jedes programm selbst löschen!
ja, habe ich doch schon mal gelesen ...
Ich habe bis jetzt EIN EINZIGES Java-Programm geschrieben (schreiben müssen)
weil's der Kunde selbst nicht hinbekommen hat. Mannoman, so etwas umständliches.
-
hehe schrieb:
nep schrieb:
Wie wärs mit Eclipse?
Haben hier in der Firma auch ein Java-Programm dass als Client für ein Web CMS dient. Das läuft ziemlich flott, obwohl es sehr viele Features hat.Eclipse startet doch total langsam und außerdem hat es mit SWT eine nicht Java GUI im Hintergund.
Bei mir startets nicht total langsam. Dass es etwas länger als z.B. Visual Studio braucht mag schon sein, bei Eclipse wird aber auch einiges an Plug-ins mehr mitgeladen.
Warum ist SWT keine Java-GUI? Nur weil es wie jede fast jede andere GUI-Bibliothek in anderen Sprachen auch die nativen APIs des Betriebssystems nutzt anstatt selbst zu zeichnen wie Swing?
-
hehe schrieb:
+fricky schrieb:
hehe schrieb:
Eclipse startet doch total langsam und außerdem hat es mit SWT eine nicht Java GUI im Hintergund.
gui ist doch egal. bei mir startet es in etwa 6 sekunden. musstu keine antike hardware nehmen.
und wie schnell startet bei dir visual studio?
minimal schneller, ich benutze aber noch vs2005.
hehe schrieb:
Die GUI ist eben nicht egal. Wie lange würde Eclipse zum starten brauchen, wenn die GUI auch komplett in Java geschrieben wäre und wäre es dann auch insgesammt langsamer?
ich benutze sonst intellij-idea fürs java-programmieren, da ist das komplette GUI in Java. ja, die grafik ist etwas langsamer als eclipse, aber nicht wirklich störend.
-
genervt schrieb:
selbst hello world startet nicht schnell
beweisen
-
byto schrieb:
genervt schrieb:
selbst hello world startet nicht schnell
beweisen
q.e.d.
-
ja, das war bis semester 2 witzig.
-
nep schrieb:
hehe schrieb:
nep schrieb:
Wie wärs mit Eclipse?
Haben hier in der Firma auch ein Java-Programm dass als Client für ein Web CMS dient. Das läuft ziemlich flott, obwohl es sehr viele Features hat.Eclipse startet doch total langsam und außerdem hat es mit SWT eine nicht Java GUI im Hintergund.
Bei mir startets nicht total langsam. Dass es etwas länger als z.B. Visual Studio braucht mag schon sein, bei Eclipse wird aber auch einiges an Plug-ins mehr mitgeladen.
Warum ist SWT keine Java-GUI? Nur weil es wie jede fast jede andere GUI-Bibliothek in anderen Sprachen auch die nativen APIs des Betriebssystems nutzt anstatt selbst zu zeichnen wie Swing?Hast du mit diesen Plug-Ins mehr Funtkionalität als mit deinem Referenz-VS?
-
Man munkelt, alle drei Java IDEs (Eclipse, IntelliJ IDEA, Netbeans) seien besser als VS. Aber eine objektive Gegenüberstellung wäre tatsächlich mal interessant.
-
Kennt ihr ein schnelles Javaprogramm? Was ist denn das fuer eine Frage?
Klar kann man in Java auch performant programmieren, man schreibt seine Programme aber anders, so dass man nicht viel mit dynamischen Variablen oder dem garbage collector zu tun hat (statische Arrays etc.).
inzwischen ausschließlich von untalentierten programmierern benutzt wird
Es wurde auch von untalentierten Programmierern entwickelt. Bestes Beispiel: Ueberladen von Methoden erlauben aber Operatoren kann man nicht neu definieren/ueberladen. Sie haben es einfach nicht verstanden.
-
knivil schrieb:
Es wurde auch von untalentierten Programmierern entwickelt. Bestes Beispiel: Ueberladen von Methoden erlauben aber Operatoren kann man nicht neu definieren/ueberladen. Sie haben es einfach nicht verstanden.
welch hartes urteil. die chance, schwer verständlichen code zu schreiben, ist hoch, wohingegen der nutzen überladener operatoren gering ist.
schau auch mal hier: http://yosefk.com/c++fqa/operator.html
-
knivil schrieb:
Kennt ihr ein schnelles Javaprogramm? Was ist denn das fuer eine Frage?
Klar kann man in Java auch performant programmieren, man schreibt seine Programme aber anders, so dass man nicht viel mit dynamischen Variablen oder dem garbage collector zu tun hat (statische Arrays etc.).
Extremer Blödsinn. Wer das heute noch glaubt, schreibt die langsamsten Programme...
-
+fricky schrieb:
welch hartes urteil. die chance, schwer verständlichen code zu schreiben, ist hoch, wohingegen der nutzen überladener operatoren gering ist.
schau auch mal hier: http://yosefk.com/c++fqa/operator.html
Selbes Argument gilt übrigens auch für Funktionen.
-
Extremer Blödsinn. Wer das heute noch glaubt, schreibt die langsamsten Programme...
Mit glauben hat das nichts zu tun. Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen. Zugegeben: es handelte sich um eine (numerische) Simulation. Umgeschrieben und es lief in akzeptabler Geschwindigkeit ohne mit einer "out of memory exception" (wegen dem Muell, der nicht aufgeraeumt wurde) abzubrechen.
PS: Deinen Kommentar finde ich recht unqualifiziert. Dumm wuerde ich sagen. Extrem voreilig.
Erinnert mich an die Typen hier: http://www.c-plusplus.net/forum/viewtopic-var-t-is-238071-and-highlight-is-.html , die einfach mal behaupten, das Laempchen des "Schraubenziehers" (Phasenpruefer) leuchtet in beiden Loechern der Steckdose (und andere Sachen). Leider haben sie es nie ausprobiert, ich schon.
-
Shade Of Mine schrieb:
+fricky schrieb:
welch hartes urteil. die chance, schwer verständlichen code zu schreiben, ist hoch, wohingegen der nutzen überladener operatoren gering ist.
schau auch mal hier: http://yosefk.com/c++fqa/operator.html
Selbes Argument gilt übrigens auch für Funktionen.
nö, nicht wirklich. einer funktion sieht man beim aufruf schon an, dass sie eine funktion ist. zweitens ist die bedeutung von operatoren vorbelegt (ein - steht z.b. für subtrahieren), was sinnvolles überladen stark einschränkt, wenn die aussage: 'ziehe x von y ab' erhalten bleiben soll.
-
knivil schrieb:
Ich habe es auf normalem Weg getan und bin schnell an die Grenzen von Java gestossen. Zugegeben: es handelte sich um eine (numerische) Simulation. Umgeschrieben und es lief in akzeptabler Geschwindigkeit ohne mit einer "out of memory exception" (wegen dem Muell, der nicht aufgeraeumt wurde) abzubrechen.
Wenn Du jemals ernsthaft versucht hättest, mit Java zu programmieren, dann müsstest Du jetzt eigentlich wissen, dass OutOfMemoryExceptions nicht entstehen, weil der Garbage Collector seine Arbeit nicht macht. Der Garbage Collector ist zuverlässig. Aber er kann natürlich nur solche Objekte einsammeln, die nicht aus Deinem laufenden Programm über irgendwelche Referenzen erreicht werden können. Der zweite Punkt, warum so eine Exception fliegen könnte ist, dass Du den Speicher für die JVM einfach viel zu gering eingestellt hast. Normalerweise haben Java-Programme nicht gerade den vollen Hauptspeicher zur Verfügung. Man muss explizit mit einem -Xmx1024m einstellen, dass das Javaprogramm zum Beispiel 1GB an Speicher nutzen darf.
Sorry, aber wenn Du denkst, OutOfMemoryExceptions hätten irgendetwas mit dem Garbage Collector zu tun, dann steht es Dir nicht zu, über Java zu urteilen. Weil Du überhaupt keine Ahnung von Java hast.
-
+fricky schrieb:
welch hartes urteil. die chance, schwer verständlichen code zu schreiben, ist hoch, wohingegen der nutzen überladener operatoren gering ist.
schau auch mal hier: http://yosefk.com/c++fqa/operator.html
Das einzige angeführte Argument gegen das Überladen von operator[] ist, dass manche IDE's diesen Syntax nicht mit ihrem IntelliSense (Ich nenne es mal so) verstehen... super Argument!
-
Deswegen steht "out of memory ..." ja auch in Anfuehrungszeichen. Konkret war's ein segmentation fault. Mittels top konnte ich zusehen, wie der Speicher anwuchs, obwohl die Menge der aktuellen Daten (auf die ich eine Referenz hatte) eher gering war. Tja und als 1.5 GByte voll waren, hats einfach Peng gemacht. Auch brauchst du mir nicht die Funktionsweise des gc's erklaeren. Er kam bei mir einfach nicht mit aufraeumen hinterher.