| 

.NET C# Java Javascript Exception

Groowe lebt!

Dies ist das Archiv des ehemaligen Forums zum Thema Groovy, Grails, Griffon und Bean Scripting Framework, welches unter groovy-forum.de existierte. Die neue Adresse des Groovy-Forums ist: http://codekicker.de/fragen/themen/groovy.


Groowe lebt!

christian - 27.02.2008 15:17
Nein Groowe ist nicht tot! Auch wenn Groovy in ein paar Tests nicht so toll abschneidet, heißt das ja nicht, dass deshalb Grails unbrauchbar wäre. Groovy ist da ja mehr der Kit zwischen großen Java-Frameworks, in denen die eigentliche Arbeit (neben der DB) stattfindet.

In einem Vergleich, den ich vor längerer Zeit mal gelesen hatte, war Grails sogar schneller als ähnliche Frameworks wie Ruby on Rails oder Django. Und damals hatte Groovy eine schlechtere Performance als heute.

Gruß
Christian


Re: Groovy Performance im Vergleich zu anderen Sprachen

wilhelm.nagy@bfw.gv.at - 27.02.2008 16:01
Nur fuers Protokoll:
Fannkuch-Test nach 51 Minuten terminiert.

\^/ili
(Wilhelm Nagy)


Re: Groovy Performance im Vergleich zu anderen Sprachen

krey - 03.03.2008 10:01
So ein extremes "Performancelag" kann ich mir nicht anders erklären.


Re: Performance klargestellt?

wilhelm.nagy@bfw.gv.at - 07.03.2008 12:00
Hallo Krey,

das die umwandlung in .class (in diesem fall) nix bringt hab ich auch schon entdekt (meine 51 Minuten waren mit .class). Mir scheint auch klar warum:

Groovy wandelt 'runtime' um (gleicht funktionalitatet wie perl) und fuehrt den tokenisierte Objektkode dann in der JVM interpretativ aus. Die Umwandlung spart IMHO also nur den Tokensierungsvorgang (ich weigere mich weiterhin von Kompelation - aus aehlichen gruenden wie du - zu sprechen).

Die Dekompelation von Groovy .class fieles soll was bringen? Natuerlich ist der Code den der decompieler erzeugt krass.
Fleisch+Mehl+Verpackung --> wurstmaschine --> WURST --> auseindaderösen wurst in einzelteilen --> zusammenbasteln der einzelteile:
wird nie wieder schnitzel

Ich denke dass man deassemblieren muesste. Den Assemblercode zu lesen und zu verstehen ist dann eine andere Sache.
Desweiteren ist groovy eine andere Sprache als Java. Also groovy -> tokensieren --> decompelieren in Java?

Dass im Groovy Interpreter nicht alles schnell geht ist "eh' kloar", sonst haetten 'SIE' nicht bei 1.0 auf 1.5 in einige teilen 45% verbesserungen erzielen können.

Die eigentliche Frage ist: Was können WIR tun? Das nicht alles zum Besten ist scheine IHNEN klar zu sein. Sollen wird den Groovy -> bytecode Umwandler zerlegen und nach performancelecks suchen?

\^/ili
(Wilhelm Nagy)


Re: Performance klargestellt?

christian - 07.03.2008 12:51
> Für groovyc gibt es leider keine Optionen um eine
> .java und eine .class Datei zu erzeugen! Sollte
> eigentlich möglich sein, oder haben die groovy
> Leute wirklich keine Ahnung vom Compilerbau?

Ich schätze mal, dass Groovy nicht erst in Java übersetzt wird, sondern direkt in Bytecode.

> Für bestimmte Abschnitte sollte man das eigentlich
> durch Annotations etc. abschalten könnten, denn es
> ist absolut überflüssig.
>
> Grade wenn es um viele simple Instruktionen wie
> bei algorithmischen Operationen geht wird das
> Ausmaß der Groovy Tragödie klar. Wenn der
> Compiler erkennt, dass das Metamodell nicht
> benutzt wird (wie beispielsweise bei den vielen
> Zuweisungen) sollte er auch nur einfache
> Instruktionen absetzen.

Nein! Groovy ist eine dynamische Sprache, die sich eben genau dadurch auszeichnet, dass ihr verhalten nicht zur Übersetzungszeit vollständig festgelegt wird. Durch diese Dynamik kann man später an allen Stellen rumschrauben, was Performance kostet.

> Guter Compilerbau
> kristalisiert sich grade dadurch heraus solche
> Optimierungspotenziale zu nutzen!

Bei "statischen Sprachen" ... Wenn man das bei Groovy machen würde, wäre man wieder bei Java.

Das Grundproblem von Groovy ist das MOP, das ja in Groovy 2.0 ersetzt werden soll. Wie gesagt, Python arbeitet auch mit Metaklassen, macht das aber wesentlich schneller als Groovy. Grundsätzlich könnte man auch mit Metaklassen noch einiges aus Groovy rausholen.

Gruß
Christian


Re: Performance klargestellt?

wilhelm.nagy@bfw.gv.at - 07.03.2008 14:20
Hi,

Zitat

So habe ich es auch verstanden! Aber wieso gibt es dann einen "groovyc" - "Compiler" wenn es im Endeffekt nur Teile tokenisiert?
Auf jeden Fall leicht zu verwechseln mit dem "javac" Compiler, der wirklich ein Binary erzeugt.

Ich verwende den term "tokenisiert" da class files nur tokenisierten aber nicht compelierten code enthalten. Unter Compieleren verstehe ich (und der rest der nicht Java-welt) halt was anderes als was javac so treibt. Dieses Code (bytecode) wird vom Java-Interpreter eingelesen (diese muss sich halt nicht mehr um die lexikalische analyse kuemmern) und kompeliert (JIT). Alles in allem ist also auch Java ein Interpreter!

Groovy liest den Groovy-code, erzeugt ohne den zwischenschritt JAVA byte-code im Hauptspeicher (groovyc schreibt diesen dann freundlicherweise als .class file). und wirft diesen dann der JVM (dem eigentlichen Javainterpreter) zur geflissentlichen verarbeitung vor. Der Bytecode enthaellt eine menge aufrufe aus dem groovy-jar. Welcher den dynamischen Teil erledigt.

Somit wird kein binary mit javac erzeugt (dieses kann man mit anderen Javacompieleren z.B. gcc/java erzeugen (.obj) und dieses linken daraus wird dann ein direkt ausführbares Programm (.exe)).

GROOVY != JAVA

Man darf groovy nicht als 'lightweight' java sehen. Groovy ist eine eigenständig Sprache, welche auf der JVM laueft (wie viele ander) Was groovy 'besser' macht ist, dass es eben .class Files erzeugen kann und somit sehr leicht mit Java verbandelt werden kann.

Zitat

Grade für die "kritischen" Prozesse ist Groovy einfach nicht einsetzbar (man siehe die Laufzeit des fannkuch Tests). Der Kern der Geschäftslogik befindet sich in den Algorithmen.

hmmm, dies ist eine typische Java aussage welche in den schulen von leuten getätigt wird die ihr leben lang noch keine zeile produktionscode verfasst haben (sorry bin vielleicht ein bisschen hart!)

Was ist in einem Projekt ein Krititscher Teil? sind die Masken unkritisch - wohl kaum, dass ist der Teil der app, welcher der Benutzer sieht. Es gibt keine unkritischen Teil in eine App. Ich habe schon erlebt, dass system abgelehnt wurden weil die Farbe der Masken nicht entsprach.

Aber um produktiv zu sein: Zeitkritische teile ein App kann man ohne problem (Groovy sei dank) in Java erstellen und diese Klassen dann in Groovy einbinden.

\^/ili
(Wilhelm Nagy)


Re: Performance klargestellt?

christian - 07.03.2008 15:39
Ich will mich jetzt nicht an dem Begriff "Bibliothek" festhalten, aber wenn man Groovy die Dynamik nehmen würde, würde man einige wesentliche Eigenschaften beschneiden. Vieles was zum Beispiel Grails macht, ist nur möglich, weil Klassen zur Laufzeit verändert werden können.

Gruß
Christian


Re: Performance klargestellt?

wilhelm.nagy@bfw.gv.at - 07.03.2008 16:18
Sorry, wenn ich schnoddrig geklungen hab - war nicht absicht.

Wenn du gcj verwendet ist es ganau das was ich mit Compiler meine, also compile -> object -> link -> exe.

Ich hab' mich ein bisschen umgesehen (auch wegen dieser Diskussion) um einen Bytecode --> exe Compiler zu finden. Es gibt da etwas aber ich habs' noch nicht ausprobiert (und weiss nichtmal ob's open-source ist). Damit muesste man auch das fannkuchen-ding zu 'flutschen' bringen. WENN es keinen bug in der Groovy->.class generierung gibt und das eigentliche problem dort liegt.
BTW: kann gcj dass viellicht auch? Ich muesste das unter windows also mit MinGW hinkriegen.

Zitat

Groovy besser als Java
Hab ich soviel ich weiss nicht geschrieben oder gemeint!
Groovy ist ein dynamischer Cousin von Java.

In anderen Diskussionen wird eben der Ansatz: "schreib Teile in Java" angedacht - ich kann dem auch nicht alzuviel abgewinnen - aber wenn sein muss...

Prozesse
Sorry, wollte keine Prozessdiskussion lostreten: im allgemeine hast' ja recht. Alles im detail zu diskutieren sprengt sicherlich das forum.
BTW: zur Erheiterung: Das mit den Farben/Formen ist wirklich passiert. Der Herr im Ministerium, versteht/verstand NICHTS von den fachlichen Anforderungen sonder sah nur die Farben (welche natuerlich mit den nutzern vorher abgestimmt worden sind), ist aber der, welcher die SW abnimmt.

Zitat

Was ich sagen wollte: Grade weil Groovy nicht Java ist, sollte man jemanden nicht zu Java Workarounds zwingen müssen um eine nutzbare Software zu erstellen.
Dieser Satz ist golden einzurahmen!

Ich denke halt, dass groovy ein grosses entwicklungspotential hat - ich wünsch' mir weniger features dazu sonder mehr Geschwindigkeit.

\^/ili
(Wilhelm Nagy)


Re: Speichermanagement in Java

christian - 17.03.2008 14:10
krey schrieb:
-------------------------------------------------------
> Wie wird der Speicher denn selbst verwaltet? (doch
> durch die JVM oder?)

Korrekt.

> In C++ gibt es auch Algorithmen um die
> Speicherverwaltung zu beschleunigen. Und da die
> JVM in C/C++ geschrieben ist, liegen Java auch nur
> die Möglichkeiten dieser Sprachen zu grunde.

Genau genommen ist der Vergleich von C/C++ und JVM etwas ungenau, denn sobald man C/C++ kompiliert, ist es kein C/C++ mehr, sondern Binärcode für die jeweilige Plattform. Das trifft auch auf die JVM zu, die natürlich nicht mehr Möglichkeiten hat, als anderes C/C++-Kompilat. Man muss Unterscheiden zwischen Speicherverwaltung durch das Betriebssystem und durch die JVM.

> Sprich: Die Speicherverwaltung die in Java so
> "intelligent" ist, wird in C/C++ abgehandelt.

Nein, sie wird durch die JVM abgehandelt, welche sich größere Speicherportionen vom Betriebssystem holt und diese "auf Vorrat" behält.

> Wie kann man Speicher verwalten ohne auf das
> Betriebssystem zugreifen zu müssen? Wenn Aktionen
> im Hauptspeicher getätigt werden sind immer
> Betriebssystem Calls notwendig.

Ja, aber eben nicht jedes mal, wie in normalen C/C++-Programmen.

Gruß
Christian


Re: Groovy Performance im Vergleich zu anderen Sprachen

christian - 03.11.2008 16:35
Zusammengefasst ist der Vorschlag, die Dynamik von Groovy teilweise abschalten zu können. Groovy wäre damit eigentlich nur eine andere Syntax für Java. So richtig gefällt mir die Idee nicht, denn ein System lebt und wo man heute keine Dynamik braucht, kann man sie vielleicht morgen gut gebrauchen ...

Da halte ich die Bestrebungen das Meta Object Protocol komplett zu überarbeiten für besser. Andere Sprachen bieten ja auch Dynamik und sind dramatisch schneller als Groovy.

Gruß
Christian


Re: Groovy Performance im Vergleich zu anderen Sprachen

christian - 10.11.2008 10:23
Was ist denn am MOP fehlerhaft? Und wie sieht es eigentlich mit dem geplanten kompletten Neuentwurf des MOP in Groovy 2 aus?

Die ewig langen Stack Traces im Fehlerfall, die ja auf das MOP zurückzuführen sind, lassen mich derzeit zögern, Groovy für Programmieranfänger zu empfehlen. Es wäre schön, wenn die endlich kompakter wären.

Gruß
Christian


Re: Groovy Performance im Vergleich zu anderen Sprachen

krey - 12.11.2008 15:03
Die sind nicht notwendig. BigDecimal regelt alles für dich!
Außerdem ist BigDecimal ein Java Konstrukt, das du nur in Groovy benutzt!

Siehe dazu: BigInteger und BigDecimal - Rechnen mit beliebiger Grösse und Genauigkeit
[www-alt.physik.uni-muenchen.de]


Stelle deine Groovy-Frage jetzt!


Diese Seite zeigt den Thread "Groowe lebt!" der ehemaligen Webseite groovy-forum.de, welche durch einen Serverunfall zerstört wurde. codekicker.de hat viele Konversationen über die beliebte Programmiersprache Groovy und zugehörige Frameworks wie das Grails-Framework retten können.

Hast Du eine Frage zum Thema Groovy, Grails oder allgemein Java? Viele ehemalige groovy-forum.de Mitglieder beantworten dir auf codekicker.de deine Frage! Stelle jetzt eine Frage!

Viele weitere Diskussionen zu Grails und Groovy befinden sich auf der Threadübersicht des alten groovy-forum.de.