Η Massif είναι μέλος της σειράς valgrind για εργαλεία κατατομής μνήμης. Ο σκοπός του είναι να δίνει μια λεπτομερή προβολή της δυναμικής χρήσης της μνήμης κατά τη διάρκεια του χρόνου ζωής ενός προγράμματος. Συγκεκριμένα, καταγράφει τη χρήση της μνήμης από το σωρό και τη στοίβα.

Ο σωρός είναι η περιοχή στη μνήμη η οποία κατανέμεται με συναρτήσεις όπως η malloc. Μεγαλώνει κατά απαίτηση και είναι συνήθως η μεγαλύτερη περιοχή της μνήμης σε ένα πρόγραμμα. Η στοίβα είναι εκεί όπου αποθηκεύονται όλα τα τοπικά δεδομένα για τις συναρτήσεις. Αυτό συμπεριλαμβάνει τις "αυτόματες" μεταβλητές στη C και τη διεύθυνση επιστροφής για τις υπορουτίνες. Η στοίβα είναι τυπικά πολύ μικρότερη και πολύ πιο ενεργή από το σωρό. Δε θα ασχοληθούμε ειδικά με τη στοίβα μια που το Massif την αντιμετωπίζει σαν να ήταν μέρος του σωρού. Το Massif παρέχει επίσης πληροφορίες για την ποσότητα της μνήμης που χρησιμοποιείται για τη διαχείριση του σωρού.

Η Massif παράγει δύο αρχεία εξόδου: μια γραφική επισκόπηση σε ένα αρχείο postscript και μια λεπτομερή ανάλυση σε ένα αρχείο κειμένου.

Η Massif έχει πολύ λίγες επιλογές και για τα περισσότερα προγράμματα δεν τις χρειάζεστε. Εντούτοις για της εφαρμογές του GNOME, όπου η κατανομή μνήμης μπορεί να θαφτεί βαθιά στο glib ή στο GTK, ο αριθμός επιπέδων κάτω από την στοίβα κλήσεων που η Massif κατεβαίνει θα πρέπει να αυξηθεί. Αυτό είναι γίνεται χρησιμοποιώντας την παράμετρο --depth. Εξ ορισμού αυτό είναι ίσο με 3· αυξάνοντας το σε 5 εγγυάται ότι η στοίβα κλήσεων θα φθάσει στον κώδικά σας. Ένα ή δύο περισσότερα επίπεδα μπορούν επίσης να είναι επιθυμητά και να παρέχουν στον κώδικά σας κάποιο πλαίσιο εφαρμογής. Δεδομένου ότι το επίπεδο λεπτομέρειας γίνεται γρήγορα συντριπτικό είναι καλύτερο να αρχίσει με μικρότερη παράμετρο βάθους και να το αυξήστε μόνο όταν γίνεται προφανές ότι αυτό δεν είναι ικανοποιητικό.

Είναι επίσης χρήσιμο να πείτε στο Massif ποιες συναρτήσεις δεσμεύουν χώρο στη μνήμη μέσω του glib. Αφαιρεί ένα περιττό στρώμα κλήσεων συναρτήσεων από τις αναφορές και σας δίνει μια σαφέστερη ιδέα ποιος κώδικας δεσμεύει χώρο στην μνήμη. Οι συναρτήσεις δέσμευσης χώρου μνήμης μέσω του glib είναι οι g_malloc, g_malloc0, g_realloc, g_try_malloc, και g_mem_chunk_alloc. Χρησιμοποιήστε την επιλογή --alloc-fn για να ενημερώστε το Masiff για αυτές.

Η γραμμή-εντολών σας πρέπει επομένως να μοιάζει κάπως σαν:

Το Swell Foop είναι το πρόγραμμα που θα χρησιμοποιούμε σαν παράδειγμα. Σας προειδοποιούμε ότι, από την στιγμή που ο valgrind θα εξομοιώνει την ΚΜΕ, θα λειτουργεί πολύ αργά. Θα χρειαστείτε επίσης πολλή μνήμη.

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

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

Η εικόνα παραπάνω παρουσιάζει μία χαρακτηριστική έξοδο δεδομένων σε μορφή postscript από το Massif. Αυτό είναι το αποτέλεσμα που θα παίρνατε παίζοντας μία πίστα από το παιχνίδι Swell Foop (έκδοση 2.8.0) και έπειτα το κλείνατε. Το αρχείο postscript θα έχει ένα όνομα όπως massif.12345.ps και το αρχείο κειμένων θα ονομάζεται massif.12345.txt. Ο αριθμός στη μέση είναι η ταυτότητα διαδικασίας του προγράμματος που εξετάστηκε. Εάν δοκιμάσετε πραγματικά αυτό το παράδειγμα θα βρείτε δύο εκδόσεις κάθε αρχείου, με ελαφρά διαφορετικούς νούμερα, αυτό συμβαίνει γιατί το Swell Foop ξεκινά μια δεύτερη διαδικασία και το Massif ακολουθεί και αυτή επίσης. Θα αγνοήσουμε αυτήν την δεύτερη διαδικασία, μια που καταναλώνει πολύ λίγη μνήμη.

Στην κορυφή της γραφικής παράστασης βλέπουμε μια μεγάλη κίτρινη ζώνη με τίτλο gdk_pixbuf_new. Αυτό φαίνεται ως ένας ιδανικός υποψήφιος για βελτιστοποίηση, αλλά θα πρέπει να χρησιμοποιήσουμε το αρχείο κειμένων για να ανακαλύψουμε τι καλεί το gdk_pixbuf_new. Στην κορυφή του αρχείου κειμένων θα εμφανίζεται κάτι σαν το επόμενο:

Η γραμμή με το σύμβολο του '=' δείχνει πόσο βαθιά κάτω είμαστε στο ίχνος στοίβας, σε αυτήν την περίπτωση είμαστε στην κορυφή. Μετά από αυτό απαριθμεί τους βαρύτερους χρήστες της μνήμης έτσι ώστε να μειωθεί ο χωρόχρονος. Ο χωρόχρονος είναι το λόγος του ποσού της μνήμης που χρησιμοποιείται και του χρόνου χρησιμοποίησης του. Αντιστοιχεί στον περιοχή των ζωνών στη γραφική παράσταση. Αυτό το μέρος του αρχείου μας λέει αυτό που ξέρουμε ήδη: το μεγαλύτερο μέρος του χωροχρόνου αφιερώνεται στο gdk_pixbuf_new. Για να ανακαλύψουν τι κάλεσε το gdk_pixbuf_new πρέπει να ψάξουμε περαιτέρω μέσα στο αρχείο κειμένου:

Η πρώτη γραμμή μας λέει ότι είμαστε τώρα τέσσερα επίπεδα βαθιά μέσα στη στοίβα. Από κάτω βρίσκεται η λίστα των κλήσεων λειτουργίας που μας οδηγεί από εδώ στο gdk_pixbuf_new. Τελικά υπάρχει μία λίστα λειτουργιών που είναι στο επόμενο κάτω επίπεδο και καλούν αυτές τις λειτουργίες. Υπάρχουν, φυσικά, καταχωρίσεις για τα επίπεδα 1, 2, και 3, αλλά αυτό είναι το πρώτο επίπεδο που φθάνει ακριβώς στον κώδικα GDK του Swell Foop. Από αυτήν την λίστα, μπορούμε να δούμε αμέσως ότι ο προβληματικός κώδικας είναι ο load_scenario.

Τώρα που ξέρουμε ποιο μέρος του κώδικά μας χρησιμοποιεί όλο χωρόχρονο μπορούμε να εξετάσουμε και να ανακαλύψουμε το γιατί. Ως αποτέλεσμα βλέπουμε ότι το load_scenario φορτώνει την pixbuf από ένα αρχείο και έπειτα δεν απελευθερώνει ποτέ την μνήμη. Αφού προσδιορίσαμε τον προβληματικό κώδικα, μπορούμε να αρχίσουμε να τον διορθώνουμε.

Μειώνοντας την κατανάλωση του χωροχρόνου είναι κάτι καλό, αλλά υπάρχουν δύο τρόποι για την μείωση του που δεν είναι ισότιμες. Μπορείτε είτε να μειώσετε το ποσό μνήμης που διατίθεται, ή μειώστε το χρονικό διάστημα που του διατίθεται. Εξετάστε για μια στιγμή ένα πρότυπο σύστημα με μόνο δύο διαδικασίες ενεργές. Και οι δύο διαδικασίες καταναλώνουν σχεδόν όλη την φυσική μνήμη RAM και εάν κάποια στιγμή επικαλύψει η μία την άλλη το σύστημα θα κάνει αντιμετάθεση και όλα θα επιβραδύνουν. Προφανώς εάν μειώνουμε τη χρήση μνήμης σε κάθε διαδικασία με παράγοντα του δύο θα μπορούν ειρηνικά να συνυπάρξουν χωρίς την ανάγκη για αντιμετάθεση. Εάν αντ' αυτού μειώσουμε το χρόνο που διατίθεται η μνήμη με παράγοντα του δύο τότε τα δύο προγράμματα μπορούν να συνυπάρξουν, αλλά μόνο εφ' όσον οι περίοδοι υψηλής χρήσης της μνήμης τους δεν επικαλύπτονται. Έτσι είναι καλύτερο να μειωθεί το ποσό μνήμης που διατίθεται.

Δυστυχώς, η επιλογή της βελτιστοποίησης περιορίζεται επίσης από τις ανάγκες του προγράμματος. Το μέγεθος των δεδομένων του pixbuf στο Swell Foop καθορίζεται από το μέγεθος των γραφικών του παιχνιδιού και δεν μπορεί να μειωθεί εύκολα. Εντούτοις, το χρονικό διάστημα που ξοδεύει κατά την φόρτωση του στη μνήμη μπορεί να μειωθεί δραστικά. Η παραπάνω εικόνα παρουσιάζει την ανάλυση του Massif για το Swell Foop μετά από την αλλαγή του για να απορρίπτει τα pixbufs μόλις φορτωθούν οι εικόνες στον διακομιστή X.

Η χρήση του χωροχρόνου από το gdk_pixbuf_new είναι τώρα μια λεπτή ζώνη που έχει σύντομες αναλαμπές (είναι τώρα η δέκατη έκτη ζώνη και βαθυπόρφυρη απόχρωση). Σαν πρόσθετο χαρακτηριστικό, η μέγιστη χρήση μνήμης έχει ελαττωθεί κατά 200 kB δεδομένου ότι η αιχμή εμφανίζεται πριν δεσμευτεί η μνήμη. Εάν δύο διαδικασίες όπως αυτή εκτελούνται από κοινού οι πιθανότητες της μέγιστης χρήσης μνήμης συμπίπτουν, και ως εκ τούτου ο κίνδυνος αντιμετάθεσης, θα είναι αρκετά χαμηλός.

Μπορούμε να το κάνουμε καλύτερα; Μια γρήγορη εξέταση της εξόδου κειμένου του Massif αποκαλύπτει ότι: το g_strdup είναι ο νέος σημαντικός ένοχος.

Εάν το εξετάσουμε ποιο ενδελεχώς θα δούμε ότι καλείται από πολλές, πολλές, διαφορετικές θέσεις.

Τώρα αντιμετωπίζουμε την ελάττωση της ανταμοιβή μας για τις προσπάθειες βελτιστοποίησής. Οι συμβουλές γραφικών παραστάσεων είναι μια άλλη πιθανή προσέγγιση: Και οι δύο ζώνες "other" και "heap admin" είναι αρκετά μεγάλες. Αυτό μας λέει ότι υπάρχουν πολλές μικρές κατανομές που έχουν γίνει από ποικίλες θέσεις. Η εξάλειψη τους θα είναι δύσκολη, αλλά εάν μπορέσουν να ομαδοποιηθούν τότε οι μεμονωμένες κατανομές μπορούν να γίνουν μεγαλύτερες και η επιβάρυνση του "heap admin" μπορεί να μειωθεί.

Υπάρχουν μερικά πράγματα που θα πρέπει να προσέξετε: Αρχικά, ο χωρόχρονος εμφανίζεται μόνο ως ποσοστό, πρέπει να το συγκρίνετε με το γενικό μέγεθος του προγράμματος για να αποφασίσει εάν το ποσό μνήμης αξίζει να δαπανηθεί. Η γραφική παράσταση, με τον κάθετο άξονα σε kilobyte, είναι ιδανικό για κάτι τέτοιο.

Αφετέρου, το Massif λαμβάνει υπόψη μόνο τη μνήμη που χρησιμοποιείται από τα προγράμματα σας. Οι πόροι όπως τα pixmaps αποθηκεύονται στον διακομιστή X και δεν εξετάζονται από το Massif. Στο παράδειγμα με το Swell Foop στην πραγματικότητα έχουμε μετακινήσει την κατανάλωση μνήμης μόνο την pixbufs από την πλευρά του προγράμματος πελάτη στα pixmaps από την πλευρά του διακομιστή. Αν και κάναμε μία μικρή απάτη, υπάρχουν κέρδη στην απόδοση. Αν κρατήσουμε τα δεδομένα εικόνας του διακομιστή X καθιστά τις ρουτίνες γραφικής αναπαράστασης γρηγορότερες και αφαιρεί πολύ διεπεξεργαστική επικοινωνία. Επίσης, τα pixmaps θα αποθηκευτούν σε μία εγγενή μορφή γραφικών που είναι συχνά συμπαγέστερο από τη μορφή 32-δυαδικών RGBA που χρησιμοποιείται από το gdk_pixbuf. Για να μετρηθεί η επίδραση των pixmaps και άλλων πόρων του διακομιστή X χρησιμοποιήστε το πρόγραμμα xrestop.