Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Ist Mono geeignet für Sandbox Spiele wie Minecraft?
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

Ist Mono geeignet für Sandbox Spiele wie Minecraft?

beantworten | zitieren | melden

Ich möchte ein eigenes Sandbox Spiel programmieren und ich frage mich, ob Mono eine gute Wahl dafür ist.

Minecraft ist in Java geschrieben und hat so seine Performance Probleme in manchen Bereichen. Da Mono vom Grundprinzip vergleichbar ist frage ich mich, ob sich nicht die gleichen Probleme ergeben.

Grundsätzlich müsste man so ein Spiel in C++ schreiben, aber konnte mich mit der Sprache noch nie anfreunden. Und Rust ist noch zu neu.

Kann man so ein Spiel in Mono entwickeln ohne in eine Performance Falle zu tappen oder wäre C++ oder Rust die bessere Wahl?

Gruß,
Markus
private Nachricht | Beiträge des Benutzers
MrSparkle
myCSharp.de - Team

Avatar #avatar-2159.gif


Dabei seit:
Beiträge: 5.649
Herkunft: Leipzig

beantworten | zitieren | melden

Hi burli70,

klingt für mich eher nach einem Anwendungsfall für Unity 3D, oder willst du die ganze 3D-Darstellung selbst entwickeln?

Ansonsten gibt es noch andere Alternativen: [FAQ] Wie finde ich den Einstieg in die 3D-Programmierung mit C#?
Weeks of programming can save you hours of planning
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Ich bin noch unschlüssig. Unity ist schon nicht verkehrt, aber ich würde das Spiel gern komplett OpenSource machen. Lieber wäre mir eine Game Engine mit OpenGL oder noch besser gleich Vulkan Support. Ganz von 0 möchte ich nicht anfangen.

Die generelle Frage ist, ob es Sinn macht, Mono überhaupt dafür zu verwenden. Mit Mono 5.0 gibt es ja eine neue Garbage Collection, die da vielleicht helfen würde.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

beantworten | zitieren | melden

Die Performanceprobleme von Minecraft direkt auf Java zu schieben, halte ich für ziemlich naiv. Die gewählte Programmiersprache ist der letzte Schuldige.

LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

So wie ich das verstanden habe verursacht der Garbage Collector die Probleme. Wenn der läuft steht der Rest. Dadurch können Ruckler enstehen. Das soll erst mit dem neuen Concurrent Garbage Collector von Mono 5.0 besser sein.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

beantworten | zitieren | melden

Darf man fragen, wo du das her hast? Ich halte das für eine ziemlich abenteuerliche Behauptung.

LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.500

beantworten | zitieren | melden

Es ist schon wahr, dass der "background collector" ein Stop-The-World Collector darstellt.
Alle Threads werden dabei gestoppt, dann wird gecleaned, und dann die Threads wieder "gestartet".
Beim Concurrent Collector wird nur ein Teil des Heaps gelockt, sodass es hier Stop-The-World Symptome nicht auftreten.

Dass aber Java grundsätzlich hier unperformant ist: absolut abenteuerliche Behauptung.
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.908
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

Ich kann hier auch in Richtung Unity 3D eine Empfehlung abgeben.
Da hast du die Engine schon komplett fertig.
Dann musst du dich nur noch um den Content(Assets wie Audio, Models und Texturen) sowie deine Skripte für die Spiellogik kümmern.

Die Performance von Java ist hier kein Problem, hab mit Java auch schon einige Jahre Erfahrung.
Hier gibt es auch in Java 9 schon Bestrebungen den GC auf den G1 umzustellen, der dann mit geringen Pausen daher kommt.
Bisher hatte ich mit dem Default GC aber nur dann hohe Pausen wenn ich wirklich unzählige Objekte hatte und den Speicher uch stark begrenzt hatte.
So musste der GC Zwangsweise mehrfach pro Sekunden die Anwendung stoppen und arbeiten.
Dies ist aber ein reiner Sonderfall den man bei Java nur bei schlechter Konfiguriation der Startparameter hinbekommt!

Das Problem von Minecraft ist eher die dynamik und die größe der Karte.
Je nachdem wie der Code von Minecraft aussieht, kann es bei zu vielen Objekten in direkter Nähe Performance Probleme geben.
Teilweise liegt es aber auch an der Hardware die man für Minecraft benötigt.
Auch wenn die Grafik mit seinen Pixel Blöcken nach Low Budget aussieht, ist hier gerade die CPU der Knackpunkt.
Dies wird aber auch bei den Optionen angezeigt, wenn man z.B. die Weitsicht auf den höchsten Wert setzt.

T-Virus
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers
Spook
myCSharp.de - Member



Dabei seit:
Beiträge: 241
Herkunft: Esslingen a.N.

beantworten | zitieren | melden

Die Frage ist wie lange der GC die Anwendung anhalten kann, ohne dass es den Benutzer stört. Dies hängt natürlich von mehreren Faktoren ab: Runtime, GC Konfiguration, Größe der Anwendung, erwartete Framerate, ...

Wenn du dieses Risiko nicht eingehen willst, dann müsstest du direkt eine Umgebung ohne GC verwenden.
Dabei solltest du bedenken, dass die GC-Zeiten wachsen werden, wenn deine Anwendung wächst. D.h. dies kann sich erst im Laufe der (Weiter)Entwicklung bemerkbar machen.

Hier ein Artikel der dir möglichweise weiterhilft:
Fundamentals of Garbage Collection
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Ich habe jetzt keine konkrete Quelle, ist aber das, was immer behauptet wird.

Für Mono hab ich das hier gefunden

http://www.mono-project.com/news/2017/05/17/concurrent-gc-news/

Selbst mit dem CGC scheint es noch Pausen zu geben, aber eben nicht mehr diese extrem langen.

Deshalb habe ich ja Bedenken vor dem Einsatz von Mono und hätte gern mal eine Meinung dazu. Ich denke nämlich, dass bei so einem Spiel der GC recht häufig aktiv werden muss, weil ja immer die Map Daten um einen Spieler herum in den Speicher geladen werden müssen und wenn der Spieler einen Bereich verlässt werden die Daten wieder freigegeben. Die muss dann der GC beseitigen. Tut er das nicht ist der Speicher irgendwann voll. Ich vermute, deshalb wird bei Minecraft immer empfohlen, Java mehr Speicher zuzuweisen.

Ich weiß nicht, wie der Java GC arbeitet und ob der auch alle Threads stoppt, aber in Anbetracht der Datenmenge und der "Symptome" klingt es zumindest plausibel.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Die Arbeitsweise von Voxelgames ist mir durchaus geläufig. Ich habe einige Erfahrung mit einem ähnlichen Spiel. Deshalb habe ich ja die Befürchtung, dass Mono vielleicht nicht ganz das richtige sein könnte

Die Größe der Map ist nicht das Problem. Es wird immer nur ein gewisser Teil der Map rund um einen Spieler in den Speicher geladen. Das muss aber auch immer wieder freigegeben werden. Je mehr Spieler in unterschiedlichen Regionen, umso mehr Daten müssen geladen und wieder freigegeben werden.

Ich vermute, dass da auch bei Minecraft der Knackpunkt ist, von Problemen wie Unmengen Entities mal abgesehen.

Da Mono 5.0 noch neu ist glaube ich auch kaum, dass schon jemand mit nennenswerten Erfahrungen aufwarten kann.
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

beantworten | zitieren | melden

Garbage Collection ist eben nicht trivial. Wenn man in den Bereich kommt, wo man den GC tunen muss, wird es haarig. Dafür merkt man dann aber auch den Unterschied zwischen Entwicklern und Fricklern. Minecraft als Beleg für schlechte Java-Performance heranzuziehen ist genau so fair,, als würde ich BER als Beleg dafür nehmen, dass Deutschland die guten Ingenieure ausgehen. Beides Quatsch.

http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Ich gebe ja nicht Java an sich die Schuld. Ich denke, dass es das generelle Konzept des GC ist, was da Probleme macht

Nochmal zu Unity: Ich glaube, dass Unity für mein Vorhaben die falschen Grundlagen bietet. Ich kann bei dem Spiel Assets usw gar nicht nutzen. Ich müsste Unity als reine Grafikengine nutzen. Außerdem soll es komplett Open Source sein.

Xenco scheint es nicht für Linux zu geben, die Delta Engine ist seit 3 Jahren nicht mehr weiter entwickelt worden, die Wave Engine ist wohl nicht Open Source.

Was mir vorschwebt ist was in Richtung Irrlicht, OGRE oder so ähnlich, aber das ist Thema für einen anderen Thread
private Nachricht | Beiträge des Benutzers
witte
myCSharp.de - Member



Dabei seit:
Beiträge: 955

beantworten | zitieren | melden

Aber was sollen wir dir denn jetzt sagen? Wir wissen es nicht welche konkreten Anforderungen du hast. Also musst du entweder selber einen Prototypen bauen oder gleich auf eine andere Programmierumgebung ausweichen, vllt C++ mit eigenen Mem-Allokatoren.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Schwer zusammen zu fassen. Das Spiel besteht aus einem Server und einem Client, die unabhängig voneinander laufen. Der Server generiert die Karte und speichert sie in einer Datenbank. Auf Anforderung stellt er sie blockweise dem Client zur Verfügung.

Im Wesentlichen geht es um die Verwaltung dieser Blöcke. Die werden immer nur so lang benötigt bis sie den Radius eines Spielers verlassen. Dann können sie gelöscht werden. Wenn sich jetzt mehrere Spieler an verschiedenen Orten bewegen kommt da eine Menge an Blöcken zusammen, vor allem auf dem Server. Dementsprechend stark kann der Speicher fragmentiert werden.

Die Frage ist, ob man verhindern kann, dass das Spiel alle paar Minuten oder sogar alle paar Sekunden für mehrere 100ms stehen bleibt. Der neue GC scheint wohl selten länger als 100ms zu blockieren, aber selbst 100ms können schon stören, besonders am Client würde das auffallen
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 985

beantworten | zitieren | melden

Dann implementiert man einen Pool, wo alle nicht mehr verwendeten Block-Instanzen weiter vorgehalten werden bis man wieder eine Block-Instanz benötigt.

Wird der Pool irgendwann zu groß, dann kann man die immer noch rauswerfen - daran würde ich mich aber erst zum Schluß begeben oder wenn der Speicher ausgeht.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Also so lang im Speicher halten wie möglich. Muss ich mir mal Gedanken machen
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 985

beantworten | zitieren | melden

Ja, denn wenn man sich bewegt fliegen hinten Blöcke raus und vorne werden welche benötigt. Ist dann quasi ein Kreislauf.

Wenn ein Berg kommt braucht man mehr und wenn man den Berg verlässt, dann sind halt viele Blöcke im Pool, die man aber wieder braucht, wenn der nächste Berg kommt (oder sich umdreht und wieder zum Berg zurückkehrt)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Deaktiviertes Profil am .
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.500

beantworten | zitieren | melden

Vor allem kostet Zeugs aus dem Speicher werfen ebenfalls Zeit und Ressourcen.
Daher ist der GC auch so konzipiert, dass er dies in seiner "freien Zeit" oder wenn unbedingt notwendig macht, und nicht dauernd.
Zitat
Da Mono 5.0 noch neu ist glaube ich auch kaum, dass schon jemand mit nennenswerten Erfahrungen aufwarten kann.

In der Open Source Welt, wie sie Mono ist, hat jeder die Möglichkeit schon vor einer Release Version Erfahrungen zu sammeln.
Und natürlich gibt es diese hier schon. Mono selbst ist aber keine komplette Neuentwicklung, sodass frühere Erfahrungen deswegen nicht gleich obsolete sind.

Für mich hört sich an, dass Du konzeptionelle Architektur-Fehler hast, die Du auf Mono/den GC schiebst.

PS @ burli70: bitte keine Full-Quotes.
Siehe auch [Hinweis] Wie poste ich richtig?
Wir Mods haben auch anderes zutun, als Deine Full quotes dauernd zu entfernen.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Zitat von Abt
Für mich hört sich an, dass Du konzeptionelle Architektur-Fehler hast, die Du auf Mono/den GC schiebst.

Nein, ich versuche nur Informationen zu sammeln, um Fehler möglichst zu vermeiden
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.500

beantworten | zitieren | melden

Auch mit einem Nein kannst Du mein Eindruck nicht verneinen.
Du hast Thesen, die Dich zu Aktionen und Aussagen verleiten.

Eine Frage wie "wie verhindere ich XY, wie gehe ich optimal vor, was sind best practises" ist doch viel hilfreicher als "ich nehme X an, daher mache ich Y. Ok?".
Deine Grundfrage, ob Mono geeignet ist, hat ja schon die These in sich, dass Du offensichtlich den Eindruck hast, dass dem eben nicht so ist. Du gehst ja auch schon direkt drauf ein, dass man so ein Spiel in C++ machen müsste; ich wüsste nicht wieso.
Schau Dir doch allein die official gallery von Unity an. Dort sind Spiele, die sind wesentlich aufwändiger als Minecraft zu sehen...

Es ist nur ein Tipp meinerseits, dass Du evtl. eine andere Herangehensweise annimmst, um die Lösung eines Problems zu finden.
Weil so wird das - siehste ja selbst - in Diskussionen ausarten, die unnötig sind und Dich selbst auch nicht voran bringt.

Nicht umsonst gibt es hier im Thread ja schon nachfragen wie Aber was sollen wir dir denn jetzt sagen?
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Ich fange einfach mal an
private Nachricht | Beiträge des Benutzers
Spook
myCSharp.de - Member



Dabei seit:
Beiträge: 241
Herkunft: Esslingen a.N.

beantworten | zitieren | melden

Analysing Pause times in the .NET GC
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Zusammengefasst: wenn der GC zu stark bremst kann ich immer noch unsafe gehen
private Nachricht | Beiträge des Benutzers
LaTino
myCSharp.de - Experte

Avatar #avatar-4122.png


Dabei seit:
Beiträge: 3.003
Herkunft: Thüringen

beantworten | zitieren | melden

Nochmal: nicht der GC ist schuld an schlechter Performance, der Entwickler ist es. Das scheint irgendwie nicht bei dir anzukommen. Das Konzept der Garbage collection ist nicht per se unperformant. Unreal engine, Unity 3D, cry engine (in Teilen)...benutzen alle garbage collection. "Wenn's an der Performance hapert, benutz ich halt unsafe"...oje.

LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 15.500

beantworten | zitieren | melden

Bei der Aussage burli70, tuts mir nicht um Dich leid, sondern mir tut es leid, dass Du etwas völlig ohne Grund die Schuld zuschiebst und das in die Welt und möglicherweise in den Bekanntenkreis trägst.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Ihr habt mich falsch verstanden. Ihr habt doch selbst gesagt, dass der GC das komplette Programm stoppen kann. Und eine Möglichkeit ist es, den Speicher ohne GC selbst zu verwalten.

Ich habe nicht mehr sagen wollen als "wenn es mit dem GC wirklich aus irgendwelchen Gründen nicht mehr geht kann ich die Daten unsafe speichern"

@LaTino: hast du den Code von Unity gesehen oder woher weißt du das? Vielleicht managen sie die Daten ja auch selbst ohne GC. Oder hast du eine Quelle für deine Aussage?
private Nachricht | Beiträge des Benutzers
Deaktiviertes Profil
myCSharp.de - Member



Dabei seit:
Beiträge: 985

beantworten | zitieren | melden

Zitat von burli70
@LaTino: hast du den Code von Unity gesehen oder woher weißt du das? Vielleicht managen sie die Daten ja auch selbst ohne GC. Oder hast du eine Quelle für deine Aussage?
Interessierte können es einfach in der Dokumentation nachlesen. Es gibt sogar Tutorials direkt bei Unity3D, die sich explizit mit dem GC und der Optimierung bzgl. dessen beschäftigen.

Wenn du ernsthaft programmieren möchtest, dann sollte der Blick in die Doku/Tutorials zum Reflex werden.
private Nachricht | Beiträge des Benutzers
burli70
myCSharp.de - Member



Dabei seit:
Beiträge: 57

Themenstarter:

beantworten | zitieren | melden

Die Unity Dokumentation ist nicht unbedingt die erste Anlaufstelle an die ich denke, wenn ich C# lernen will, auch wenn sich ein Blick vielleicht lohnt.

Und eine Erklärung des GC in der Doku ist kein Beleg dafür, dass Unity intern ausschließlich managed Code verwendet. Die Doku bezieht sich, so weit ich das bisher gesehen habe, auf das Scripting in C#. Sollte ich was übersehen haben könnte es daran liegen, dass ich zur Zeit nur mit einem Handy und 64k Bandbreite ins Internet komme. Also verzeiht mir, wenn ich da gerade nicht so schnell bin.

Nochmal: der GC kann trotz aller Optimierungen zu einem Problem in einem Spiel werden. SOLLTE das der Fall sein kann man den GC einfach umgehen und die problematischen Daten einfach selbst speichern und verwalten. Richtig oder falsch?

Und jetzt beruhigen wir uns alle wieder und diskutieren normal weiter
private Nachricht | Beiträge des Benutzers
T-Virus
myCSharp.de - Member



Dabei seit:
Beiträge: 1.908
Herkunft: Nordhausen, Nörten-Hardenberg

beantworten | zitieren | melden

@burli70
Mit unsafe kannst du deine "Daten" selbst Verwalten.
Aber wie eben schon alle sagen, ebenfalls auch mein letzter Post, gibt es nur sehr sehr selten Fälle in denen man sowas braucht/machen muss.
Der GC ist auch schon soweit in C# optimiert, dass es selbst in Spielen nur dann zu einem Problem kommen kann, wenn man schon falsch programmiert.
Damit der GC dauerhaft zum Problem wird, müsstest du z.B. unmengen an Objekten erzeugen.

Gutes Beispiel dafür wäre mit eingie Threads große Byte Arrays anzulegen in einer schleife und dann dem GC beim collecten zu sehen.
Aber wie schon mehrfach von Abt und Sir Rufo erwähnt, liegt es dann am Code nicht an C#/.Net etc.

Alle die dir hier antworten, haben schon Jahre lang Erfahrungen mit C# und verdienen auch ihr Geld damit, mich mit eingeschlossen.
Wenn Sie dir sagen, dass unsafe hier Unsinn ist und du dem GC vertrauen kannst, dann hat dies auch schon Jahre an Erfahrung als Grundlage.

Unsafe ist auch der falsche Ansatz für Spieleprogrammierung und wird auch nur in Fällen benötigt, in denen der GC eben nicht eingreifen darf.
Dies sind aber Fälle, die selbst in der Spieleprogrammierung sehr selten sind.

Wenn du dem GC nicht vertraust, was an deinen Posts abgeleitet werden kann, dann bist du bei C#/.Net an der falschen Adresse.

Auf Platformen wie Steam und co. tummeln sich sogar seit Jahren Spielen, die in C#/.Net entwickelt wurden.
Dort kannst du dich an die entsprechenden Entwickler wenden ob diese unsafe o.ä. benötigen.
Meistens wird dies aber nicht der Fall sein, da dort entweder Xna oder Wrapper für populäre Libraries wie SDL/SDML zum Einsatz kommen.
Diese werden dann mit P/Invoke auf die eigentlichen Libs gemappt und können dann selbst die Handles ohne unsafe durch Disposen freigeben lassen.

Man kann in C# die meisten Sachen ohne unsafe in reinem Manged Code schreiben.
Nur wenn es sehr Platformnah, also eben über Zeiger laufen muss, dann braucht man unsafe.
Ansonsten kannst du alles ohne große Probleme mit C# in Manged Code machen.
Der GC ist hier immer dein Freund, wenn er mal mehr machen muss als gedacht, dann musst du deinen Code prüfen.
Nicht selten erstellt man mal in Schleifen immer wieder benötigte Objekte von großen Klassen, die dann wieder weg geräumt werden müssen.

Nachtrag:
Sir Rufo bezog sich eigentlich nicht nur auf die Unity Dok sondern generell sollte man die Dokus lesen.
Guter Anfang wäre z.B. für dich auch mal die MSDN Dokus zu .Net zu lesen.
Das Thema unsafe sollte dir auch klar machen, dass dies nur dann benötigt wird, wenn du mit Zeigern und Unmanged Resourcen arbeiten musst.

Nachtrag 2:
Zum Thema GC Pausen.
In der Regel dauern diese nur wenige Millisekunden oder bei gutem Code, gibt es sogar über einen längeren Zeitraum mal keine.
In der Regel sollten die Pausen auch nur in Millisekunden Bereich liegen.
Schon ab rund 100ms sind die Pausen für schnelle Spiele wie Shooter zu lang.
Aber hier schreitet der GC auch nur ein, wenn du massiv Daten erstellst und verwirft.

Gerade beim Thema GC solltest du dir am besten mal ein einfaches Konsolen Programm bauen und schauen wie sich der GC verhält und was du machen musst um diese länger collecten zu lassen.
Ich denke heir musst du einfach deine eigenen Erfahrungen sammeln, dann siehst du auch wie der GC arbeitet und ob er den wirklich so böse ist, wie du denkst :)

T-Virus
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von T-Virus am .
Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
private Nachricht | Beiträge des Benutzers