Πρώτα Βήματα - Γλώσσες προγραμματισμού

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Wed, 09 Feb 2011 17:33:49 GMT

Γι αυτό και έβαλα την περιττή MoveTriangle για να δεις ότι και με 800.000 επαναλήψεις, πάλι δεν αλλάζει τίποτε. Όσο για τα αντικείμενα που δημιουργούνται ενδιάμεσα, ε ναι. Και στην VB6 πάλι δεν θα τα δημιουργούσες? Και δεν θα έτρωγες το performance hit επειδή θα τα καθάριζες ένα-ένα αντί όλα μαζί στο τέλος? Ο λόγος που ο garbage collector δεν εκτελείται συνέχεια είναι ότι το καθάρισμα κοστίζει σε CPU. Αντί για πολλά μικρά καθαρίσματα έχεις ένα μεγάλο, μόνο όταν χρειαστεί.

Αν σκεφτείς ότι στόχος σου είναι να τελειώσει ο υπολογισμός γρηγορότερα, ή να μπορέσεις με το ίδιο μηχάνημα να επεξεργαστείς περισσότερα τρίγωνα, θα δεις ότι το κυνήγι της μνήμης είναι δευτερεύον. Για παράδειγμα, είναι ΚΑΛΟ να μην μοιράζεσαι αντικείμενα, γιατί έτσι μπορείς να τα επεξεργαστείς παράλληλα. Διαφορετικά, cores τα οποία προσπαθούν να επεξεργαστούν διαφορετικά τρίγωνα θα αναγκαστούν να περιμένουν το ένα το άλλο αν αυτά τα τρίγωνα "μοιράζονται" κορυφές.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

fanisg — Wed, 09 Feb 2011 17:24:58 GMT

Ευχαριστώ πολύ για όλο τον κόπο που κάνετε.

Καταρχήν δεν μπορώ να χρησιμοποιήσω repository & references (κάτι που προσπάθησα μεν, απλά δεν μου έκανε) διότι πολλά αντικείμενα δημιουργούνται (και πρέπει να διαγράφονται) ως ενδιάμεσα στάδια υπολογισμών. Εκεί έχω βασικά το πρόβλημα (φαντάζομαι). Κατά τα άλλα η λογική είναι θεωρητικά αντίστοιχη με τον κώδικα της παράθεσης, απλά όλες οι διαδικασίες των σύνθετων οντοτήτων, ενώ χρησιμοποιούν ως βάση την απλή οντότητα τύπου Poiint3D, δημιουργούν είτε ως τελικά είτε ως ενδιάμεσα αποτελέσματα άλλα σύνθετα ή απλά αντικείμενα τα οποία πρέπει εν τέλει να αλληλεπιδράσουν με το αρχικό... μπάχαλο...

Πήρα ωστόσο μια καλή γραμμή από όσα γράψατε. Ελπίζω να έχω καλά νέα σύντομα.

Respect

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Tue, 08 Feb 2011 23:26:45 GMT

fanisg:
Ξεκίνησα σουλούπωμα... δεν θέλω τα αντικείμενα να είναι references, πρέπει να είναι αυτόνομα.

Εξακολουθείς να μπερδεύεις τις έννοιες. Δεν είναι τα αντικείμενα references ούτε υπάρχουν αντικείμενα που δεν είναι αυτόνομα. Αυτόνομα είναι όλα. Όταν όμως χρησιμοποιείς ένα αντικείμενο, ουσιαστικά χρησιμοποιείς ένα reference, ένα pointer στην πραγματική του θέση στη μνήμη. Ακόμα και struct αν είναι το αντικείμενο, μέσω reference του μιλάς. Reference σημαίνει "αναφορά". Αναφέρεσαι σε ένα αντικείμενο, δεν είσαι το αντικείμενο.

Επίσης, η έννοια της "αυτονομίας" δεν υπάρχει. Το ότι ο garbage collector ελέγχει τα references μεταξύ των αντικειμένων δεν σημαίνει ότι υπάρχει κάποια εξάρτηση μεταξύ τους, το αντίθετο. ΕΠΕΙΔΗ ΕΙΝΑΙ ΑΝΕΞΑΡΤΗΤΑ πρέπει να τα ελέγξει. Αν υπήρχε σχέση parent child, ένα child δεν θα μπορούσε ποτέ να κρατήσει ζωντανό ένα parent. Η κορυφή δεν θα μπορούσε ποτέ να κρατήσει ζωντανό ένα τρίγωνο. Αυτό όμως δεν συμβαίνει.

Ακόμα και αν χρησιμοποιήσεις structs τα οποία περνάς στα functions byval (οπότε δημιουργείς αντίγραφα) δεν θα κάνεις τίποτε γιατί το πρόβλημα δεν ήταν το byval αλλά οι σχέσεις μεταξύ των αρχικών αντικειμένων.

Δοκίμασε πρώτα με καθαρά αντικείμενα και χωρίς πειρασμένες παραμέτρους στις μεταβλητές, χωρίς αντικείμενα που "μοιράζονται", για να δεις πως δουλεύει κανονικά το .NET και μετά δοκίμασε τις βελτιώσεις. Η συμπεριφορά που βλέπεις τώρα δεν είναι ομαλή και οφείλεται στις παρεμβάσεις που έχουν γίνει.

Τώρα, για να πεισθούμε ότι όντως δεν χάνεται μνήμη και τα references δεν φταίνε, έφτιαξα τις παρακάτω κλάσεις για τρίγωνα:

 public class Point3D
        {
            public int X { get; set; }
            public int Y { get; set; }
            public int Z { get; set; }
        }

        public class Triangle
        {
            public Point3D[] Vertices { get; set; } 
        }

Και έφτιαξα και μία λίστα με 800.000 τρίγωνα, τα οποία πειράζω με τον παρακάτω κώδικα:

 static void Main(string[] args)
        {
            Console.WriteLine("Idle");
            Console.ReadKey();
            
            var triangles = Generate(800000);            
            
            Console.WriteLine("Generated");
            Console.ReadKey();

            Move(triangles);
            
            Console.WriteLine("Moved");
            Console.ReadKey();
        }

        private static void Move(List<Triangle> triangles)
        {
            foreach (Triangle triangle in triangles)
            {
                MoveTriangle(triangle);
            }
        }

        private static void MoveTriangle(Triangle triangle)
        {
            foreach (Point3D edge in triangle.Vertices)
            {
                edge.X += 10;
                edge.Y += 10;
                edge.Z += 10;
            }
        }

        public static List<Triangle> Generate(int count)
        {
            var triangles=new List<Triangle>();
            var r=new Random();
            for(int i=0;i<count;i++)
            {
                triangles.Add(new Triangle {
                                Vertices=new [] {
                                        new Point3D{X=r.Next(),Y=r.Next(),Z=r.Next()},
                                        new Point3D{X=r.Next(),Y=r.Next(),Z=r.Next()},
                                        new Point3D{X=r.Next(),Y=r.Next(),Z=r.Next()},
                                    }});
                
            }
            return triangles;
        }

Η μνήμη του προγράμματος ανεβαίνει στα 90 MB περίπου μόλις δημιουργηθούν τα αντικείμενα και παραμένει εκεί, παρότι (ή μάλλον επειδή) η λίστα και τα αντικείμενα περνάνε ως references στη Move και τη MoveTriangle.

Δοκίμασα επίσης να βγάλω τον κώδικα Generate, Move σε function και να το επαναλάβω 100 φορές. Αυτό που είδα ήταν ότι η μνήμη ανεβοκατέβαινε μεταξύ 90 και 160 MB καθώς ο GC δεν έτρεχε αμέσως μετά από κάθε iteration. Αυτό όμως δεν με επηρέαζε καθώς στο τέλος η μνήμη πάντα καθάριζε.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

George J. Capnias — Tue, 08 Feb 2011 22:26:06 GMT

fanisg:
Πάμε από την αρχή:
1. Να χρησιμοποιώ απλή εκχώρηση (=) ή clone;
2. Τα references στο ίδιο αντικείμενο επιβαρύνουν τη μνήμη αθροιστικά;

Έχοντας πρόσφατες μνήμες παρόμοιου εγχειρήματος - φαντάσου οικοδομικά τετράγωνα που έπρεπε να ομαδοποιηθούν με διάφορα κριτήρια:

Φόρτωσα όλα τα οικοδομικά τετράγωνα σε μια λίστα από custom objects - new για κάθε νέο object,
στην συνέχεια για καθένα από αυτά, περιείχε μια λίστα από τα γειτονικά του τετράγωνα - το .Add στην λίστα έβαζε το αποτέλεσμα ενός LINQ query με το Id του τετραγώνου
Η κύρια εργασία ήταν να φτιαχτούν ομάδες από τετράγωνα (custom object). που και πάλι υπήρχαν .Αdd στην λίστα από κριτήρια αναζήτησης - LINQ query - επάνω στα γειτονικά τετράγωνα κάθε τετραγώνου

Καταλαβαίνεις ότι για κάθε τετράγωνο, το αντικείμενο είχε από ένα reference σε κάθε γείτονά του, αλλά και στην λίστα της ομάδας που άνηκε. Αν και υπήρχαν διαδικασίες που έβγαζαν οικοδομικά τετράγωνα από τις λίστες των ομάδων και τα έβαζαν σε άλλες ομάδας, δεν αντιλήφθηκα κάπου να έχω πρόβλημα, είτε στο perfomance, είτε στο να μένουν "σκουπίδια" στην μνήμη. Τα references είναι ουσιαστικά counters που χρησιμοποιεί ο GC για να ξέρει αν θα πρέπει να απελευθερώσει την μνήμη όταν ένα object έχει μαρκαριστεί σαν "deleted".

Θα πρότεινα να ξαναδείς το project σου από την αρχή, ώστε να υπάρχει κάποιο κεντρικό repository των αντικειμένων που είναι το βασικό στοιχείο και όπου αλλού τα χρειάζεσαι, να τα περνάς σαν reference μέσα από το repository σου.

George J.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Tue, 08 Feb 2011 21:14:45 GMT

Αντώνη, αυτά είναι μερικά από τα νούμερα που σου δίνουν και οι profilers. Οι profilers όμως πάνε παρακάτω και σου δίνουν και πληροφορίες για τους τύπους των αντικειμένων, πού και πότε έγιναν allocate και άλλες πληροφορίες. Πέρα από τα performance counters χρησιμοποιούν και το Profiling API για να σου δείξουν περισσότερες πληροφορίες.

Σωτήρη, δεν νομίζω ότι το caching έχει νόημα. Υποψιάζομαι ότι το μοίρασμα των κορυφών είναι μία προσπάθεια να "σωθεί" μνήμη. Αλήθεια, πόση μνήμη πιάνουν αυτά τα 800.000 αντικείμενα? Γιατί αν π.χ. μιλάμε για τρίγωνα τότε (800.000 τρίγωνα * 3 κορυφές * 3 σημεία * 4 bytes) = 27 ΜΒ! Δεν είναι δα και τίποτε φοβερό.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

fanisg — Tue, 08 Feb 2011 21:10:16 GMT

Ξεκίνησα σουλούπωμα... δεν θέλω τα αντικείμενα να είναι references, πρέπει να είναι αυτόνομα. Πιστεύω πως τότε θα μπορέσει να γίνει εκκαθάριση.

Για τα τυπικά, ο κώδικας δεν είναι 20.000 χύμα γραμμές, απλά είναι πολλές κλάσεις οι οποίες κληρονομούν και κληρονομούνται. Η κάθε κλάση προσφέρει τις μεθόδους και τα constructors της αυτόνομα. Θα επανέλθω αν δεν βγάλω και πάλι άκρη, πιθανώς για απόδοση υπεργολαβικά της εκκαθάρισης και τακτοποίησης.

Σας ευχαριστώ για το χρόνο σας. Respect & many thanks to all.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Antonios Chatzipavlis — Tue, 08 Feb 2011 21:06:09 GMT

απλά να συνεισφέρω και εγω στην ζητήση...

αν πατε στο performance monitor του λειτουργίκου ( start > run > perfmon ), μπορείτε να προσθέσετε κάτι όμορφους μετρητές (.ΝΕΤ CLR Memory) που υπάρχουν ψηλααα στην λίστα των objects και να διαλέξετε όλους με την αντίστοιχη εφαρμογή... ώστε να δούμε νουμερακια ωραία και χρήσιμα

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

cap — Tue, 08 Feb 2011 21:05:15 GMT

fanisg:
@cap:
Ναι, χρησιμοποιώ διπλότυπες τιμές που δεν χρειάζονται, μέχρι αποδείξεως του εναντίον. Π.χ. 2 τρίγωνα που μοιράζονται την ίδια κορυφή. Θα μπορούσε το 2ο να πάρει το σημείο ως reference του πρώτου. Αν στην πορεία όμως έπρεπε τα τρίγωνα να "ξεκολλήσουν" ή ακόμα χειρότερα το 1ο να διαγραφεί;

Τότε ένας συνδυασμός sharing όπου χρειάζεται και copy όπου πάλι χρειάζεται ίσως σου ελευθέρωνε λίγη μνήμη.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Tue, 08 Feb 2011 21:03:36 GMT

fanisg:
@cap:
Ναι, χρησιμοποιώ διπλότυπες τιμές που δεν χρειάζονται, μέχρι αποδείξεως του εναντίον. Π.χ. 2 τρίγωνα που μοιράζονται την ίδια κορυφή. Θα μπορούσε το 2ο να πάρει το σημείο ως reference του πρώτου. Αν στην πορεία όμως έπρεπε τα τρίγωνα να "ξεκολλήσουν" ή ακόμα χειρότερα το 1ο να διαγραφεί;

Τί λες, ότι έχεις ένα αντικείμενο-κορυφή το οποίο χρησιμοποιείται από 2 τρίγωνα? Ε τότε, αν δεν ελευθερώσεις και τα δύο τρίγωνα, δεν πρόκειται να διαγραφούν ούτε αυτά ούτε η κορυφή. Από τη στιγμή που κάπου υπάρχει reference στο ένα τρίγωνο, άρα και στην κορυφή του, άρα υπάρχει και στο 2ο τρίγωνο μέσω της κορυφής του. Και αν είναι πολλά αυτά τα "μοιράσματα" θα καταλήξεις με όλα τα αντικείμενα αλληλομπλεγμένα στη μνήμη.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Tue, 08 Feb 2011 20:59:10 GMT

fanisg:

Αν το refernce γεννάει αντικείμενα τότε η μόνη λύση είναι το clone?

Το reference δεν γεννάει αντικείμενα, είναι απλά ένα "pointer" σε μία θέση μνήμης. Αν βλέπεις πολλαπλά αντικείμενα είναι γιατί τα κρατάς εσύ κάπου. Απλά και μόνο ότι μπερδεύεις reference με clone (που όντως δημιουργεί αντικείμενα) σημαίνει ότι πρέπει να πατήσεις φρένο.

Απομόνωσε και δοκίμασε τον κώδικα σου για να δεις ποιά είναι η "νορμάλ" συμπεριφορά, και να πεισθείς ότι η γή είναι στρογγυλή και ο ήλιος κίτρινος. Όσο προσπαθείς να βρεις bug στο .NET θα χάνεις το χρόνο σου. Άσε που αν έχεις 20.000 μονολιθικό κώδικα ο οποίος δεν μπορεί να σπάσει, χρειάζεται σίγουρα καθάρισμα.

Επίσης, ο profiler πρέπει να σου δίνει πληροφορίες για το που έχουν γίνει τα allocations, που υπάρχουν ακόμα references και σίγουρα πόσα αντικείμενα είναι ακόμα στη μνήμη και έχουν ξεφύγει από garbage collections. Τί σου λέει? Σε ποιά generations βρίσκονται τα αντικείμενα? Μήπως έχεις ορίσει destructors? Στην περίπτωση αυτή τα αντικείμενα παραμένουν περισσότερο στη μνήμη γιατί ο GC πρέπει να καλέσει τον destructor, όχι απλά να καθαρίσει τη μνήμη.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

dimos.homatas — Tue, 08 Feb 2011 20:51:06 GMT

Ρε παιδιά, μήπως υπάρχει και το απλό ενδεχόμενο να μην φτάνει η μνήμη γιατί μπορεί το κάθε αντικείμενο να είναι μεγάλο σε μέγεθος; Αν είναι το κάθε ένα 10K, τότε μιλάμε για 8 GB μόνο για να μπούνε στην μνήμη!

800.000 instances, 20.000 γραμμές κώδικα... bloated κατάσταση μου μυρίζει και μάλλον είναι θέμα ανάλυσης/σχεδιασμού.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

fanisg — Tue, 08 Feb 2011 20:48:38 GMT

@cap:

Ναι, χρησιμοποιώ διπλότυπες τιμές που δεν χρειάζονται, μέχρι αποδείξεως του εναντίον. Π.χ. 2 τρίγωνα που μοιράζονται την ίδια κορυφή. Θα μπορούσε το 2ο να πάρει το σημείο ως reference του πρώτου. Αν στην πορεία όμως έπρεπε τα τρίγωνα να "ξεκολλήσουν" ή ακόμα χειρότερα το 1ο να διαγραφεί;

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

fanisg — Tue, 08 Feb 2011 20:44:12 GMT

Δεν το θεώρησα χαζή ερώτηση! Απλά δεν ξέρω αν θα μπορούσε να γίνει & αλλιώς. Structures γενικά δεν χρησιμοποιώ. Ο profiler είναι της SCITECH (.NET Memory Profiler).

Ο κώδικας των συνδεδεμένων κλάσεων είναι >20.000 γραμμές, γενικά "δουλειά" του είναι να παράγει νέες χωρικές οντότητες. Το πρόβλημά μου είναι αν πρέπει ή όχι να κάνω εξ'ολοκλήρου references ή clone.

Αν το refernce γεννάει αντικείμενα τότε η μόνη λύση είναι το clone?

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

Παναγιώτης Καναβός — Tue, 08 Feb 2011 20:41:48 GMT

fanisg:
1. New γίνεται σε κάθε αρχικοποίηση στιγμιοτύπου (υποχρεωτικά;)
2. Το Clone το χρησιμοποιώ συνειδητά μόνο σε ορισμένες περιπτώσεις, όπου ακολουθεί με το πέρας εκκαθάριση και =nothing.
3. Απ'όσο γνωρίζω όχι.

Δεν χρησιμοποιώ καθόλου unmanaged resources, com objects, dll & activex περασμένων τεχνολογιών. Αλλά πλέον δεν είμαι σίγουρος αν κάνω καλά...!

Το σφάλμα σου είναι ότι προσπαθείς να περάσεις γνώσεις και συνήθειες ενός τελείως διαφορετικού περιβάλλοντος (VB6) στο .NET. Δεν έχει πρόβλημα το .ΝΕΤ αλλά ο τρόπος (ακόμα δεν μας έδειξες τον κώδικα) που το χρησιμοποιείς. Ο Garbage Collector φτιάχτηκε ακριβώς για να ΜΗΝ χρειάζεται να ψαχουλεύεις που να σβήσεις αντικείμενα. Αν δεν καταλαβαίνεις πως δουλεύει και προσπαθείς να τον "αναγκάσεις" να συμπεριφερθεί όπως νομίζεις, θα έχεις πρόβλημα. Για παράδειγμα, μήπως κοιτάς τη μνήμη πριν προλάβει ο GC να τρέξει? Αν δεν υπάρχει βαρειά χρήση μνήμης στο μηχάνημα ο GC δεν τρέχει (γιατί να το κάνει?) για να μην σπαταλήσει CPU. Όταν χρειαστεί το κάνει. Εδώ που τα λέμε, και σε Java ή σε C++ με garbage collection library αν δούλευες, θα αντιμετώπιζες παρόμοια προβλήματα μέχρι να αφήσεις τον GC να δουλέψει.

Αντί να προσπαθείς να περάσεις παλιό κώδικα σε νέο περιβάλλον, φτιάξε μερικές απλές εφαρμογές για να δεις πως δουλεύει το .NET. Για να λύσεις τις απορείες σου για το memory deallocation, φτιάξε ένα απλό console app και βάλε μέσα μία λίστα με 800.000 αντικείμενα. Καθάρισε τη και δες πως και πότε καθαρίζεται η μνήμη. Έτσι θα απομονώσεις το πρόβλημα και δεν θα έχεις τις παρεμβολές όλης της υπόλοιπης εφαρμογής.

Απ: Πρόβλημα με την απελευθέρωση μνήμης στη VB.NET

cap — Tue, 08 Feb 2011 20:38:56 GMT

Συνεχίζω να υποψιάζομαι πρόβλημα "ζωντανών" references πάντως. Δυστυχώς δεν μπορώ να αναπτύξω το συλλογισμό μου παραπάνω και να επιβεβαιώσω την υποψία μου χωρίς να έχω source code.

Ερώτηση - σκέψη (στο μοτίβο σκέψης του flyweight): Ολα τα instances τα χρειάζεσαι ως ξεχωριστά; Μήπως χρησιμοποιείς νέα στιγμιότυπα με εντελώς διπλότυπες τιμές χωρίς να είναι απαραίτητο να το κάνεις; Μήπως ένας "κουβάς" που θα ελέγχει αν το στιγμιότυπο που ζητάς υπάρχει ήδη και θα σου δίνει reference σε αυτό αντί για ένα νέο θα σου μείωνε τον αριθμό;