Java vs. .NET
- Ersteller waki87
- Erstellt am
h^2
hat ne Keule +1
Ich dachte immernur java sei so eine Bastelsprache möchtegernmodernern Universitätsprofessoren 
Meinereiner hat zumindest noch nie ein ernsthaftes Programm gesehen was in Java geschrieben ist und in meiner ganzen Unix-Zeit hatte ich noch nie eine Java-VM installiert, außer für die Uni mal zwei Wochen den GCJ.
Aber vielleicht liegt das auch an meinem sozialen und technischen Umfeld
edit: mit .NET habe ich natürlich auch nichts zu schaffen. Das heißt, davon habe ich noch weniger gehört als von Java, ich glaube die Microsoft Student Partners (!) machen da so Werbe-Workshops für, aber laut Augenzeugen, kommt da auch niemand vorbei, obwohl es Kekse umsonst gibt
Meinereiner hat zumindest noch nie ein ernsthaftes Programm gesehen was in Java geschrieben ist und in meiner ganzen Unix-Zeit hatte ich noch nie eine Java-VM installiert, außer für die Uni mal zwei Wochen den GCJ.
Aber vielleicht liegt das auch an meinem sozialen und technischen Umfeld
edit: mit .NET habe ich natürlich auch nichts zu schaffen. Das heißt, davon habe ich noch weniger gehört als von Java, ich glaube die Microsoft Student Partners (!) machen da so Werbe-Workshops für, aber laut Augenzeugen, kommt da auch niemand vorbei, obwohl es Kekse umsonst gibt
Zuletzt bearbeitet:
Die JVM ist zum ausführen von Java Programmen gedacht. Nicht zum Programmieren. Von daher hast du sie wahrscheinlich sogar jetzt noch installiert...
SAP ist nichts ernsthaftes? Aber jedem das seine. Java ist nicht für jeden Zweck was. Aber das ist bei jeder Programmiersprache so. Von daher gibt es keine beste Sprache.
h^2
hat ne Keule +1
Ne habe ich nicht, weil ich ja garkeine Java-Programme habe…
wie gesagt, ich bin wahrscheinlich durch mein Umfeld geprägt, das sind hauptsächlich Desktop-User und Hacker.
Ja, ich benutze ja auch unteschiedliches von sh und awk, über python bis c++.
-Nuke-
Well-Known Member
Du brauchst bloß die Security-Update-Doku bei Linux/Windows/OS X/Flash/whatever lesen. Dort ist es in so ziemlich allen Fällen ein Pufferüberlauf.
Was haben denn Sicherheitslücken mit Popularität zu tun? Man gucke sich alleine mal die Bugfixes von Apple an. ~50 Sicherheitlücken in WebKit gestopft. Alle die Code-Ausführung erlauben war ein Buffer-Overflow. Oder Adobe. ~29 Sicherheitslücken in Flash. Alles Buffer-Overflows.
Die Liste kannst du endlos fortsetzen.
Wenn eine Lücke von 1000 anderen mal etwas anderes ist, muss man die 1000 nicht gleich abschreiben
Und ich verlange auch gar nicht die Nutzung von Java oder .NET. Ein (bisher nicht wirklich existierendes) Managed-C(++), wäre schon mal ein gewaltiger Sprung in der Computer-Sicherheit. Microsoft hat sowas ähnliches in ihre C(++)-Runtime und Compiler eingebaut. Seitdem ist Windows auch deutlich schwerer zu knacken.
Und Java ist auch nicht wirklich eine Randsprache. Gerade im Bereich der Webanwendungen ist Java quasi Marktführer.
Auch meiner Meinung nach ist es in jeder Programmiersprache möglich, unsicheren Code zu schreiben. Zu den hier vorgebrachten Argumenten möchte ich aber doch ein paar Einwände bringen:
Dieses Problem tritt auch in Bezug auf Immutable Objekte bzw. "Copy-by-Value" Objekte auf. Wenn man mit Objekten arbeitet, deren Informationen veralten können, muss man deren Aktualität prüfen. Das Argument könnte man also bei nahezu jeder Programmiersprache bringen.
Einige der grössten Webseiten bzw. viele Enterprise Systeme und WebServices sind in Java geschrieben. Um die zu nutzen muss man auch selbst kein Java installiert haben.
Zum Thema:
Ich finde den Film Klasse
Dieses Problem tritt auch in Bezug auf Immutable Objekte bzw. "Copy-by-Value" Objekte auf. Wenn man mit Objekten arbeitet, deren Informationen veralten können, muss man deren Aktualität prüfen. Das Argument könnte man also bei nahezu jeder Programmiersprache bringen.
Ich dachte immernur java sei so eine Bastelsprache möchtegernmodernern Universitätsprofessoren
Meinereiner hat zumindest noch nie ein ernsthaftes Programm gesehen was in Java geschrieben ist und in meiner ganzen Unix-Zeit hatte ich noch nie eine Java-VM installiert, außer für die Uni mal zwei Wochen den GCJ.
Einige der grössten Webseiten bzw. viele Enterprise Systeme und WebServices sind in Java geschrieben. Um die zu nutzen muss man auch selbst kein Java installiert haben.
Zum Thema:
Ich finde den Film Klasse
rudy
aint no stoppin us now
Hallo Nuke, hallo Forum,
also stimme Dir in Deiner Analyse fast uneingeschränkt zu, dann Buffer-Overflows dazu ist folgendes festzuhalten:
Buffer-Overflow Attacken - Das Einschleusen von Programmcode über eine http:// Anfrage - sind nur in C und eingeschränkt in C++ möglich. Basis dafür ist das die Verwaltung von Zeichenketten in C ganz dem Programmierer obliegt. Und wenn dieser nicht nachdenkt was passiert wenn man ihm einen http:// String von 1 KByte Länge gibt und er nur mit 100 Zeichen rechnet, weil eine URL kleiner ist dann überschreibt der String eben Rücksprungadressen mit eigenem Code der beim Rücksprung ausgeführt wird. Der Trojaner ist im System und mit Vollmachten der Anwendung aktiv. Eine fehlende Call by Reference Schnittstelle die mühsam mit Pointern emuliert werden muss. Wen diese mal ins Nirwana zeigen gibt es die schönsten Dinge, wobei ein Blue-Screen noch etwas harmloses ist.
Dann in sicherheitsrelevanten Unternehmen wird C aber auch C++ nicht nur nicht eingesetzt sondern abgelehnt!
Das DoD und die NASA arbeiten mit ADA und zwar deshalb. Auffällig ist das gerade im Bereich Raumfahrt-Luftfahrt-Millitär, wo Software einfach immer funktionieren muss und man nur begrenzte Testmöglichkeiten hat, C und C++ nicht angewandt werden darf!
MFG
oenone
Well-Known Member
Die Programmiersprache heißt "Ada", das ist ein Eigenname, den auch die gute Lady Ada, Countess of Lovelace trug, nach der die Sprache benannt wurde. Es ist also keine Abkürzung und somit wird sie nicht "ADA" geschrieben.
Zum Thema DoD und NASA, die benutzen auch viel Java und stellen vieles darauf um. Ich durfte einigen Code davon sehen und muss sagen, wenn die Satelliten die nächsten 5 Jahre noch im Orbit sind, dürfen wir uns glücklich schätzen.
Oh, zurück zum Topic.. Es geht ja um Java und .Net, nicht um C, C++ oder Ada!
In der Industrie wird leider immer mehr nach Java und .Net verlangt. Und dann wundern sich die Manager, dass sie leistungsfähigere Hardware brauchen als früher, oder dass es langsamer wird.
Zum Thema "Java ist langsam":
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html?page=1
Auch hier: Langsame Programme lassen sich in jeder Sprache implementieren . Aber dass Java langsam sei ist eine sehr veraltete Aussage.
Die Terabyte/Petabyte Sort Benchmarks werden auch regelmäßig von Java-basierten Systemen gewonnen.
Beispiel:
http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html
http://hadoop.apache.org/
http://blog.dhananjaynene.com/2008/07/performance-comparison-c-java-python-ruby-jython-jruby-groovy/
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html?page=1
Auch hier: Langsame Programme lassen sich in jeder Sprache implementieren
. Aber dass Java langsam sei ist eine sehr veraltete Aussage.Die Terabyte/Petabyte Sort Benchmarks werden auch regelmäßig von Java-basierten Systemen gewonnen.
Beispiel:
http://developer.yahoo.net/blogs/hadoop/2008/07/apache_hadoop_wins_terabyte_sort_benchmark.html
http://hadoop.apache.org/
-Nuke-
Well-Known Member
Das ist doch Käse. Wie auch unter C(++) sorgt die Unfähigkeit der Programmierer für langsame Programme und nicht die gewählte Sprache. Das Einzige was bei Java/.NET langsamer ist, ist die Startzeit der Anwendungen, aber auch nur, wenn auf dem System die VM nicht schon laufen sollte.
Stattdessen hat man weitaus weniger Probleme mit Anwendungen unter Managed-Sprachen:
- keine Speicherfragmentierung (großes Problem bei größeren C(++) Anwendungen), wird meist mit einem entsprechenden Speichermanager gelöst, was einem Garbage-Collector nahe kommt
- weniger Sicherheitsbedenken
- leichtere Portierung auf andere Plattformen (im Fall .NET und Java)
- CPU-Unabhängig. Es ist in der Entwicklung egal ob der Kunde einen x86, x86_64, PowerPC, Itanium oder ARM-Prozessor nutzt, ganz anders als in C(++)
- sollte das Managed-System über einen JITC verfügen, kann dieser auf die Host-CPU optimieren
- deutlich bessere IDEs
- bessere Umsetzung der Standards (welcher C(++)-Compiler deckt bitte den ganzen C(++) Standard ab?)
Ein gutes Beispiel ist z.B. die H2-Datenbank, welche zu 100% in Java geschrieben ist und sich hinter MySQL und PostgreSQL nicht verstecken braucht (Feature und Performancemäßig), dabei nur knapp eine 1,2 MB JAR-Datei ist und sich darin ein Webserver samt Datenbankadministration befinden. Das mach mal nach
Sobald der Garbage-Collector mal anläuft ist Java grottenlangsam. Die Auswirkungen sind nach meiner Erfahrung phenomenal-katastrophal.
Meine Strategie Java zu betreiben ist der JVM so viel Speicher zuzuweisen, dass der Garbage-Collector wirklich nur dann anlaufen muss, wenn gerade nichts anderes zu tun ist.
Meine Strategie Java zu betreiben ist der JVM so viel Speicher zuzuweisen, dass der Garbage-Collector wirklich nur dann anlaufen muss, wenn gerade nichts anderes zu tun ist.
-Nuke-
Well-Known Member
Java hat diverse Garbage-Collectoren. Vllt. einfach nur für deinen Fall den falschen gewählt? ggf. auch mal den neuen G1 getestet?
Jungs, nun macht doch keinen Sprachflamewar draus. Man muss Fragen wie diese pragmatisch sehen. Schaut mal, ich bin beruflich meist im Bereich kleine Systeme bis Embedded unterwegs. Für das was ich mache, ist Java mehr oder minder ungeeignet. Zu groß ist der Overhead gegenüber einem schnellen, sauberen C-Programm. Einerseits in Sachen CPU (Ja, ich weiß, dass Java in etwa gleichschnell sein kann, die meisten Java-Programme sind es aber nicht.), vor allem aber im Speicher. Java ist nunmal eine Speichersau, zumindest in dem Bereich, da die Laufzeitumgebung oftmals schon wesentlich größer als ein C-Programm ist. Privat beschäftige ich mich mit Dingen, wo es auf jeden CPU-Zyklus ankommt. Auch da will man eigentlich kein Java, außer man hat einen Fetisch darauf sich im wahrsten Sinne des Wortes totzuoptimieren.
Aber ist Java daher eine schlechte Sprache und generell Murks? Nein. Javas Stärken liegen in anderen Bereichen. Wenn ich große Anwendungssysteme schreibe, Dinge die nicht performancekritisch sind, sind gemanagte Sprachen wie Java ein Segen. Weil ich auf viele Ecken und Kanten keine Rücksicht mehr nehmen muss. Das sind besagte Pufferüberläufe, es ist ein großer Teil des Speichermanagements und so weiter. Vor allem senken Java und seine Kollegen die Gefahr, dass weniger begabter Programmierer (*hust*) da was verbocken drastisch. Nicht zuletzt ist der Frustfaktor geringer, was auch nicht zu verachten ist.
Oder anders gesagt: Use the right tool for the right job.
Aber ist Java daher eine schlechte Sprache und generell Murks? Nein. Javas Stärken liegen in anderen Bereichen. Wenn ich große Anwendungssysteme schreibe, Dinge die nicht performancekritisch sind, sind gemanagte Sprachen wie Java ein Segen. Weil ich auf viele Ecken und Kanten keine Rücksicht mehr nehmen muss. Das sind besagte Pufferüberläufe, es ist ein großer Teil des Speichermanagements und so weiter. Vor allem senken Java und seine Kollegen die Gefahr, dass weniger begabter Programmierer (*hust*) da was verbocken drastisch. Nicht zuletzt ist der Frustfaktor geringer, was auch nicht zu verachten ist.
Oder anders gesagt: Use the right tool for the right job.
s-tlk
Lion King Fan
Fuer zeitkritische Anwendungen und besonders im Industriebereich ist Java auch denkbar ungeeignet. Wenn ploetzlich der Garbage Collector einspringt, um den Speicher aufzuraeuemen und dadurch irgendeine Maschine nicht zur richtigen Zeit, das richtige tut, dann steht man ziemlich dumm da. Deshalb wuerde wohl nie einer auf die Idee kommen Java in so einer Situation einzusetzen, genau so wenig wie .NET, wobei das hier wohl auch andere Gruende hat.
Wenn man sich nichts vormacht, dann liegt der 'Erfolg' von Java auch eigentlich nur in der Verbreitung an den Unis. Es ist traurig, das in vielen Faellen fast nichts anderes mehr gelehrt wird. Da muss man sich nicht wundern, das es derart viele mehr oder minder gute Java Applikationen gibt.
Ueber .NET kann man ja sagen was man will, aber es hat auch einige interessante Ansaetze, obwohl ich niemals eine Programmiersprache benutzen wuerde, die nur reell auf einem einzigen OS vernuenftig laeuft. Aber man hat sich bei denen doch einige Gedanken ueber die Zukunft gemacht und interessante Konzepte wie PLINQ, TPL, Task... usw eingebaut, die besonders die paralle Programmierung effizient und schnell gestalten, um damit der modernen Computerwelt gerecht zu werden.
Trotzdem behaupte ich, das man als (echter mehr hardware orientierter *duck*) Prorammierer am besten weiss, wann welche Aktion besonders gut positioniert ist und demnach moechte ich eine Programmiersprache, die dort moeglichst einfach und ohne viel Gefummel zu handhaben ist.
Das steht dann denen natuerlich gegenueber, die einfach nur _irgendwie_ was zum laufen kriegen wollen und das moeglichst schnell und billig auf vielen Plattformen.
Wenn man sich nichts vormacht, dann liegt der 'Erfolg' von Java auch eigentlich nur in der Verbreitung an den Unis. Es ist traurig, das in vielen Faellen fast nichts anderes mehr gelehrt wird. Da muss man sich nicht wundern, das es derart viele mehr oder minder gute Java Applikationen gibt.
Ueber .NET kann man ja sagen was man will, aber es hat auch einige interessante Ansaetze, obwohl ich niemals eine Programmiersprache benutzen wuerde, die nur reell auf einem einzigen OS vernuenftig laeuft. Aber man hat sich bei denen doch einige Gedanken ueber die Zukunft gemacht und interessante Konzepte wie PLINQ, TPL, Task... usw eingebaut, die besonders die paralle Programmierung effizient und schnell gestalten, um damit der modernen Computerwelt gerecht zu werden.
Trotzdem behaupte ich, das man als (echter mehr hardware orientierter *duck*) Prorammierer am besten weiss, wann welche Aktion besonders gut positioniert ist und demnach moechte ich eine Programmiersprache, die dort moeglichst einfach und ohne viel Gefummel zu handhaben ist.
Das steht dann denen natuerlich gegenueber, die einfach nur _irgendwie_ was zum laufen kriegen wollen und das moeglichst schnell und billig auf vielen Plattformen.
*unterschreib*
@Yamagi: Also von einem Bekannten weiß ich, dass Java auch auf schwächeren Systemen, wie Routern verwendet wird.
Zu "Javas" Stärken zählt wohl vor allem auch, dass es überall gelehrt wird und das ist wohl vor allem als gutes Marketing zu betrachten. Früher hatten ja auch Pascal und Delphi eine größere Verbreitung, weil es viel unterrichtet wurde.
Viele User bringen viele Vorteile und noch mehr User. Java ist halt nett, weil es C(++)-ähnliche Programmierung mit den Vorteilen, die einer virtuellen Maschine verbindet. Aber sie hat Stärken und Schwächen, wie jeder andere Sprache auch.
Wie fast jede andere Sprache. Perl 6 hat nur Stärken und kommt diesen Sommer!
Zu Ada wollte ich noch fragen, warum das nur in speziellen Bereichen angewandt wird. Hatte mir die Sprache schon vor einer Weile angesehen und sie ist ja nicht hässlich und kompliziert. Auch Bindings scheint es für fast alles zu geben. Zu wenig Hype?
Für Flamewars gibt es übrigens Heise und Slashdot
Zu "Javas" Stärken zählt wohl vor allem auch, dass es überall gelehrt wird und das ist wohl vor allem als gutes Marketing zu betrachten. Früher hatten ja auch Pascal und Delphi eine größere Verbreitung, weil es viel unterrichtet wurde.
Viele User bringen viele Vorteile und noch mehr User. Java ist halt nett, weil es C(++)-ähnliche Programmierung mit den Vorteilen, die einer virtuellen Maschine verbindet. Aber sie hat Stärken und Schwächen, wie jeder andere Sprache auch.
Wie fast jede andere Sprache. Perl 6 hat nur Stärken und kommt diesen Sommer!
Zu Ada wollte ich noch fragen, warum das nur in speziellen Bereichen angewandt wird. Hatte mir die Sprache schon vor einer Weile angesehen und sie ist ja nicht hässlich und kompliziert. Auch Bindings scheint es für fast alles zu geben. Zu wenig Hype?
Für Flamewars gibt es übrigens Heise und Slashdot
Ja, Java wird auf schwächeren Geräten verwendet. Zum Beispiel basiert die Blu-Ray Technologie auch in größerem Maßstab auf Java, praktisch jeder Player hat aus gutem Grund ein entsprechendes Logo auf der Rückseite. Nur bei dem was ich hier treibe ist es denkbar ungeeignet, nicht generell.
-Nuke-
Well-Known Member
Öhm, man hat eigentlich nur bestimmte Aspekte funktionaler Programmiersprachen auf die objektorientierten Sprachen angewendet. Langfristige Zukunft sehe ich generell eher in den entsprechenden Sprachen wie F#, Scala, etc.
Und für zeitkritische Anwendungen gibt es auch bestimmte Spezifikationen für ein "RealTime-Java". http://java.sun.com/javase/technologies/realtime/index.jsp Für Embedded-Systeme gibt's auch entsprechende Sachen, aber dort herrscht halt noch C(++) vor, weil die Nachfrage nach etwas "modernerem" auch nicht allzu groß ist.
Und der große Erfolg von den Sprachen wie .NET und Java liegt auch zum großen Teil an den ziemlich ausgereiften Business-Frameworks. Gerade was Frameworks für ORM, Web usw. angeht sieht C(++) einfach alt aus
Aber mir ging's hauptsächlich darum mehr Sachen in Sprachen zu entwickeln, die auf ihre Buffer aufpassen
kili
just me
Das hast Du aber mal wieder fein gecopied&pasted.
Die Quelle haettest Du aber auch ruhig mal angeben sollen:
http://www.bernd-leitenberger.de/echte-programmierer-neu.shtml
(Den Text dort finde ich uebrigens eher peinlich)
kili
just me
Ja, weil es Heerscharen billiger Uni-Abgaenger gibt, die oft waehrend des Studiums nichts anderes als Java oder C# gesehen haben. Was wiederum moeglicherweise eine Folge der Java- und C#/.Net-Hypes waren, waehrend dem sich (vermutlich) jede Menge Hochschulpersonal davon hat ueberzeugen lassen, dass Java und/oder C#/.Net die Zukunft sind und alles andere Scheisse ist.
Nunja, das mag *mit* an dem Java und .Net liegen, aber es liegt oft auch daran, dass viele Entwickler sich halt gar keine Gedanken ueber Effizienz und Speichersparsamkeit machen sondern schnell mal was zusammenpfuschen. Habe ich schon -zig mal gesehen, in -zig verschiedenen Programmiersprachen.
h^2
hat ne Keule +1
Jein, ich kann zwar langsamen code mit C++ schreiben, aber ich kann bestimmte Sachen mit Java einfach nicht machen. Wenn ich z.B. bestimmte Formen von Polymorphie verwende, dann mache ich dazu in C++ die calls virtual. Das ist praktisch und läuft dann sowie in Java, kostet aber (durch das Anlegen der VTABLE wird das Objekt größer, beim Aufruf passiert erst ein lookup in der VTABLE etc).
Das tolle bei C++ ist, dass ich es nicht benutzen muss wenn ich es nicht brauche und dadurch Zeit und Platz spare. Dann gibt es noch generische programmierung, die sehr effizient ist. Das geht schonmal garnicht mit java.
Ich behaupte nicht, dass das sehr komfortabel ist oder dass es immer auf performance ankommt, aber wenn es drauf ankommt, ist es einfach Quatsch zu behaupten Java sei so schnell wie C++. Ist es einfach nicht in einigen Szenarien. und da limitiert mich ganz klar die Sprache. Egal wie toll ich bin, bestimmte Sachen, wird mir Java nicht machen.
(standard java ist dafür vielleicht angenehmer bei OOP als standrd c++, wobei man durch Sachen wie Qt auch wieder ein gutes Level an OOP mit C++ erreicht)
h^2
hat ne Keule +1
Die sind ja langsam, zu Hochzeiten schaffe 100 programme am Tag.... auch in C++!link schrieb:
rofl, lol,
-Nuke-
Well-Known Member
Die Frage ist inwieweit die Optimierungen des JiT-Compilers das bisschen wieder rausholen.
Denn im Gegensatz zu C/C++ kann der HotSpot-Compiler von Java den Code dauernd profilen und ggf. neu ordnen und besser optimieren.Doch, eigentlich schon
Das kommt wohl auch auf den entsprechenden Benchmark an. Es ist auch Quatsch zu behaupten C++ sei schneller als Java
In Scimark 2 ist Java schneller als der GCC4.2 -O3 Code Wie gesagt, in Normalfall sind die Szenerien stark begrenzt wo C++ den Sprachvorteil hat, wenn es um Geschwindigkeit geht. Dafür erbt man viele Probleme (wie genannt). Und hackt man UTF-16-Strings, Speicherprüfung etc. in C++ mit rein, landet man auch ganz schnell hinter Sprachen wie Java.
In der Theorie mögen "native" Sprachen schneller sein, aber in der Praxis landet man dann doch nur in speziellen Szenerien die im Normalfall (== ein Standard-Desktop-System) gar nicht greifen. Die Sicherheit würde sich aber bei einer Managed-Sprache (muss ja nicht Java sein) schon eben deutlich erhöhen. Stattdessen bunkert man Programme in Sandboxes (z.B. Chrome), betreibt intensive manuelle Speicherchecks, die Managed-Sprachen einfach schon von Haus aus liefern (und zwar hochoptimiert, an internen Strukturen etc. und nicht dauernd char-Array-Längen zählen).
kili
just me
Das Problem mit Garbage Kollectoren (ist das jetzt eigentlich perfektes Denglisch?) ist, dass sie irgendwo zwischen Fluch und Segen pendeln.
Simple Mark/Sweep oder 2-Space Copy-Kollektoren schwenken die weisse Fahne, wenn sie "zu voll" sind, d.h. wenn das Programm neben GC kaum noch dazu kommt, was sinnvolles zu tun. Das kann ein Problem in der GC-Implementierung sein, dass kann auch ein simples Memoryleak im Programm sein (dann fliegt man aber schnell mit OOM raus).
Kompliziertere Implementierungen generational GC rennen entweder mit einem Sack von Heuristiken, die entscheiden, was wann in welchen Space geschoben wird, oder sie moechten entsprechende Parameter von aussen mitgegeben bekommen, damit sie optimal arbeiten. Letzteres will man auch nicht gerade; oder wer kann schon zielsicher beurteilen, wie lange ein Objekt leben muss, bis es in den Old-Space geschoben wird?
Andererseits habe ich mal (vor laengerer Zeit) ein Paper gelesen, in dem anhand von Allerweltsproblemen gezeigt wurde, dass u.U. GC sogar effizienter als explizite Speicherverwaltung (via malloc, calloc, realloc, free) sein kann. Wenn ich mich nur erinnern koennte, wo ich das Paper her hatte ;-)
Ein Problem mit GC ist uebrigens auch, dass es echt keinen Spass macht, wenn ein Programm nicht mehr in den Verfuegbaren physikalischen Speicher passt und zu swappen anfaengt. Das merke ich regelmaessig, wenn ich mal den GHC auf meinem kleinen i386er mit 128MB RAM bauen will (einen groesseren i386er habe ich z.Z. nicht, und haette auch gar keinen Platz dafuer).
-Nuke-
Well-Known Member
Das ist eigentlich allgemein bekannt. Ein X x = new X() ist in Java keine teure Angelegenheit. Dort wird zur Not auch einfach ein bereits als gelöscht markiertes Objekt genommen und einfach neu initialisiert.
Bei C++ ist ein X *x = new X() und dessen Löschung eine recht teure Angelegenheit, weil jedes mal Speicher angefordert wird und anschließend auch (je nach Implementierung von free) wieder genullt wird. Man ungeht das u.U. mit händischen realloc usw. In Managed-Sprachen ist auch das "for-free".
Von Speicherfragmentierung bei länger laufenden Systemen gar nicht zu reden. Dort wird's dann teilweise auch eng bei 1GB freiem Speicher noch 100MB am Stück zu kriegen. Garbage-Collectoren räumen selbst auf. Speichermanager für C++ gibt's ja, aber das grenzt dann auch schon bald an einem Garbage-Collector.