Δεκτό για τους destructors (btw και για το σαρδάμ
), αλλά και πάλι, το θέμα με τα cyclic references προδίδει ότι εξακολουθούν να υφίσταται concerns για το memory management, που όταν μιλάμε για application development είναι απλά απαγορευτικό. Όλα είναι συνάρτηση μεταξύ επιδόσεων και κόστους ανάπτυξης, όπου στο δεύτερο συμπεριλαμβάνεται προφανώς και το
testing, στο οποίο συνήθως τέτοια πράγματα έρχονται για να σε στοιχειώσουν.
Σε τελική ανάλυση, αφού είμαστε performance analysis nazis, ας δούμε τα εξής δεδομένα:
- Σε μια garbage collected γλώσσα, η υπολογιστική επιβάρυνση συνίσταται σε (ας πούμε) 50-100 ms ανά τυχαία χρονικά διαστήματα (συνήθως κλάσεις αρκετών δευτερολέπτων), προκειμένου να πραγματοποιηθεί το context switching για τον gc, και φυσικά η επακολουθούμενη απελευθέρωση της μνήμης. Αν κάτσει να το ζυγίσει κανείς αυτό σοβαρά, αντιλαμβάνεται ότι το κόστος - για την πλειοψηφία τύπου εφαρμογών - είναι ουσιαστικά ανύπαρκτο.
Σε μια arc υλοποίηση από την άλλη, δεν υφίσταται το κόστος του garbage collection, αλλά αυτό δε σημαίνει ότι δεν υφίσταται κόστος γενικότερα (here comes the nazi-ing): από τη στιγμή που μιλάμε για reference counters per object, ουσιαστικά αναφερόμαστε σε πόρους οι οποίοι απαιτούν exclusive access από καθέναν που προσπαθεί να τις ενημερώσει. Κοινώς, για κάθε αναφορά που δημιουργείται στο runtime, απαιτείται ένα extra σταθερό κόστος το οποίο δεν υφίσταται στα garbage collected συστήματα (και που προφανώς είναι ακριβότερο από ένα απλό i++)
Οπότε τι είναι προτιμότερο performance-wise; Πιθανόν να είναι το arc, πιθανόν και όχι, πιθανόν επίσης να εξαρτάται ανά περίπτωση. Το θέμα όμως είναι πως για να το διαπιστώσουμε, πρέπει κυριολεκτικά να βγάλουμε τα σταγονόμετρα, και να μετρήσουμε τις διαφορές. Σε αυτή την περίπτωση, η "ταμπακιέρα" εκπίπτει από το performance, και έρχεται στο τι βολεύει αρχιτεκτονικά τον προγραμματιστή. Ως προς αυτό, το garbage collection υπερτερεί κατά πολυ.
Σε ό,τι αφορά τα real-time applications, θα ήμουν διατεθειμένος να βάλω νερό στο κρασί μου, αλλά αλήθεια, για ποια τέτοια apps μιλάμε σε mobile environments; Εκτός αν η Apple έχει αρχίσει να αναπτύσει iPhone apps για πυρηνικούς αντιδραστήρες ή διαστημόπλοια, το μόνο πλησιέστερο πράγμα που μπορώ να σκεφτώ σε real-time, είναι εφαρμογές τύπου VoIP ή ηλεκτρονικών δημοπρασιών. Και εκεί, από τη στιγμή που το bottleneck του performance είναι το δίκτυο, δε βλέπω καν λόγο να συζητάμε για το "performance penalty" του garbage collection. Βέβαια, αν είναι τόσο σημαντικό, το Android π.χ. (μιας που το αναφέραμε), διαθέτει και native development kit (ndk), για τους λάτρεις των ρετρό απολαύσεων της C++
- Spoiler: εμφάνιση/απόκρυψη
Μιας που αναφέρθηκαν και τα διαστημόπλοια:
[url]http://www.computerworld.com/s/article/9238700/NASA_launches_new_nanosatellites_Android_smartphones[/url]
Όταν το performance μετράει, η επιλογή είναι μονάχα μία :-D
Πάντως για να μην παρεξηγούμαι, δεν προσπαθώ να αποδείξω ότι το gc αποτελεί κάποιου είδους άγιο δισκοπότηρο. Απλά το point που θέλω να δώσω, είναι πως ως developers (του παρόντος ή του μέλλοντος) έχουμε περισσότερα πράγματα να λαμβάνουμε υπόψιν από το να ξεψειρίζουμε το micro-optimization (εξού και το λογοπαίγνιο της assembly
). To κόστος παραγωγής και συντήρησης του software, είναι ένα από αυτά. Όπως φυσικά και το performance, αλλά μετρούμενο πάντα στα σωστά πλαίσια (platform capabilities, application/object life-cycle, etc)
Υ.Γ.1: Τα περί Android που "χωλαίνει" είναι απλά αστικός μύθος, μάλλον προερχόμενος από το τμήμα μάρκετινγκ του Μήλου. Το θέμα είναι ποια είναι τα standards συγκρισης: η μπουρούχα των 80 - 100 euro προφανώς θα σέρνεται. Από την άλλη, εγώ π.χ. ακόμα περιμένω κάποιον Apple user να έρθει να κοντράρει στα σοβαρά το Nexus μου
Υ.Γ.2: Μήπως να μεταφερθεί αυτό το off-topic περί memory management σε κάποιο dedicated thread; Είναι αν μη τι άλλο αρκετά ενδιαφέρον!