Κάντε σφραγισμένο μαθήματα προσφέρουν πραγματικά οφέλη απόδοσης;

ψήφοι
118

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

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

Έχει κανείς την εκτέλεση δοκιμών και να δει τη διαφορά;

Βοήθησέ με να μάθω :)

Δημοσιεύθηκε 05/08/2008 στις 13:00
πηγή χρήστη
Σε άλλες γλώσσες...                            


11 απαντήσεις

ψήφοι
133

Η απάντηση είναι όχι, σφραγίζεται τάξεις δεν έχουν καλύτερες επιδόσεις από τους μη-σφραγισμένο.

Το θέμα έρχεται προς τα κάτω για να το callvs callvirtIL κώδικες op. Callείναι ταχύτερη από ό, τι callvirt, και callvirtχρησιμοποιείται κυρίως όταν δεν ξέρεις αν το αντικείμενο έχει subclassed. Έτσι οι άνθρωποι υποθέτουν ότι αν σφραγίσει μια τάξη όλοι οι κωδικοί op θα αλλάξει από το calvirtsνα callsκαι θα είναι ταχύτερη.

Δυστυχώς callvirtκάνει άλλα πράγματα που το καθιστούν χρήσιμο πάρα πολύ, όπως και ο έλεγχος για μηδενική αναφορές. Αυτό σημαίνει ότι ακόμα και αν η κατηγορία είναι σφραγισμένη, η αναφορά μπορεί να εξακολουθεί να είναι μηδενική και συνεπώς callvirtείναι απαραίτητη. Μπορείτε να πάρετε γύρω από αυτό (χωρίς να χρειάζεται να σφραγίσει την τάξη), αλλά γίνεται λίγο άσκοπο.

Δομές χρησιμοποιούν callεπειδή δεν μπορούν να subclassed και δεν είναι ποτέ μηδενική.

Δείτε αυτό το θέμα για περισσότερες πληροφορίες:

Κλήση και callvirt

Απαντήθηκε 24/12/2008 στις 03:09
πηγή χρήστη

ψήφοι
46

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

Υπάρχουν πολύπλοκοι κανόνες σχετικά με τον τύπο κλήσης, εικονική / nonvirtual, και εγώ δεν τα ξέρω όλα γι 'αυτό δεν μπορεί να περιγράψει πραγματικά για σας, αλλά αν το google για κλειστές τάξεις και εικονικές μεθόδους που μπορείτε να βρείτε κάποια άρθρα σχετικά με το θέμα.

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

Εδώ είναι ένα link που παραπέμπουν σε αυτό: Rambling στο σφραγισμένο λέξη-κλειδί

Απαντήθηκε 05/08/2008 στις 13:32
πηγή χρήστη

ψήφοι
20

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

Αλλά είναι στο χέρι εφαρμογή compiler και το περιβάλλον εκτέλεσης.


Λεπτομέριες

Πολλές από τις σύγχρονες επεξεργαστές χρησιμοποιούν μεγάλες δομή του αγωγού για την αύξηση της απόδοσης. Επειδή η CPU είναι απίστευτα πιο γρήγορα από τη μνήμη, CPU πρέπει να γίνεται προαναζήτηση κώδικα από τη μνήμη για την επιτάχυνση του αγωγού. Εάν ο κωδικός δεν είναι έτοιμος στην κατάλληλη στιγμή, οι αγωγοί θα είναι σε αδράνεια.

Υπάρχει ένα μεγάλο εμπόδιο που ονομάζεται δυναμική αποστολή που διαταράσσει αυτή την βελτιστοποίηση «προανάκληση». Μπορείτε να καταλάβετε αυτό ως μόνο υπό όρους διακλάδωση.

// Value of `v` is unknown,
// and can be resolved only at runtime.
// CPU cannot know code to prefetch,
// so just prefetch one of a() or b().
// This is *speculative execution*.
int v = random();
if (v==1) a();
else b();

CPU δεν μπορεί να γίνεται προαναζήτηση δίπλα κώδικα για να εκτελέσει σε αυτή την περίπτωση, επειδή η επόμενη θέση κώδικας είναι άγνωστος μέχρι να επιλυθεί η κατάσταση. Έτσι, αυτό το κάνει κινδύνου προκαλεί αδράνεια του αγωγού. Και πρόστιμο επιδόσεις από αδράνεια είναι τεράστια στην τακτική.

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

Μερικά CPU (συμπεριλαμβανομένων των x86 chips τελευταία της Intel) χρησιμοποιεί την τεχνική που ονομάζεται κερδοσκοπικές εκτέλεσης να χρησιμοποιήσει αγωγό, ακόμη και για την κατάσταση. Απλά γίνεται προαναζήτηση ένα από διαδρομή εκτέλεσης. Αλλά ποσοστό επιτυχίας αυτής της τεχνικής δεν είναι τόσο υψηλή. Και αποτυχία κερδοσκοπία προκαλεί στάβλο αγωγού που κάνει επίσης τεράστια ποινή απόδοσης. (αυτό είναι εντελώς από την εφαρμογή της CPU. μερικά κινητά CPU είναι γνωστό ότι δεν κάνει αυτό το είδος της βελτιστοποίησης για την εξοικονόμηση ενέργειας)

Βασικά, C # είναι μια στατικά καταρτίζονται γλώσσα. Αλλά όχι πάντα. Δεν γνωρίζουμε την ακριβή κατάσταση και αυτό εξαρτάται αποκλειστικά από την εφαρμογή compiler. Μερικοί μεταγλωττιστές μπορεί να εξαλείψει τη δυνατότητα της δυναμικής αποστολής εμποδίζοντας τη μέθοδο επιτακτικό αν η μέθοδος έχει επισημανθεί ως sealed. Stupid compilers δεν μπορεί. Αυτό είναι το όφελος επιδόσεις του sealed.


Αυτή η απάντηση ( γιατί είναι πιο γρήγορα για να επεξεργαστεί ένα ταξινομημένο πίνακα από ένα μη ταξινομημένα σειρά; ) περιγράφει την πρόβλεψη υποκατάστημα πολύ καλύτερα.

Απαντήθηκε 03/02/2011 στις 16:22
πηγή χρήστη

ψήφοι
18

Ενημέρωση: Από το .NET πυρήνα 2.0 και .NET Desktop 4.7.1, η CLR υποστηρίζει τώρα devirtualization. Μπορεί να πάρει τις μεθόδους σε σφραγισμένους κατηγορίες και να αντικαταστήσει εικονικών κλήσεις με απευθείας κλήσεις - και μπορεί επίσης να το κάνετε αυτό για μη σφραγισμένες κατηγορίες αν μπορώ να καταλάβω ότι είναι ασφαλές να το πράξει.

Σε μια τέτοια περίπτωση (α σφραγισμένο τάξη που η CLR δεν θα μπορούσε διαφορετικά να ανιχνεύσει ως ασφαλές να devirtualise), ένα σφραγισμένο τάξη πρέπει πραγματικά να προσφέρει κάποιου είδους πλεονέκτημα απόδοσης.

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

https://blogs.msdn.microsoft.com/dotnet/2017/06/29/performance-improvements-in-ryujit-in-net-core-and-net-framework/


Αρχικό Απάντηση:

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

public class NormalClass {
    public void WriteIt(string x) {
        Console.WriteLine("NormalClass");
        Console.WriteLine(x);
    }
}

public sealed class SealedClass {
    public void WriteIt(string x) {
        Console.WriteLine("SealedClass");
        Console.WriteLine(x);
    }
}

public static void CallNormal() {
    var n = new NormalClass();
    n.WriteIt("a string");
}

public static void CallSealed() {
    var n = new SealedClass();
    n.WriteIt("a string");
}

Σε όλες τις περιπτώσεις, η C # compiler (Visual Studio 2010 στην διαμόρφωση κατασκευή Τύπου) εκπέμπει πανομοιότυπα MSIL, η οποία έχει ως εξής:

L_0000: newobj instance void <NormalClass or SealedClass>::.ctor()
L_0005: stloc.0 
L_0006: ldloc.0 
L_0007: ldstr "a string"
L_000c: callvirt instance void <NormalClass or SealedClass>::WriteIt(string)
L_0011: ret 

Η συχνά-ανέφερε λόγος που οι άνθρωποι λένε σφραγισμένο παρέχει οφέλη απόδοσης είναι ότι ο compiler ξέρει η τάξη δεν είναι overriden, και ως εκ τούτου μπορούν να χρησιμοποιούν call, αντί της callvirt, καθώς δεν πρέπει να ελέγξετε τα virtuals, κλπ Όπως αποδεικνύεται παραπάνω, αυτό δεν είναι αληθής.

επόμενη σκέψη μου ήταν ότι ακόμα κι αν η MSIL είναι ίδια, ίσως οι JIT compiler αντιμετωπίζει σφραγισμένες κατηγορίες με διαφορετικό τρόπο;

Έτρεξα μια μεταγλώττισης υπό την οπτική εντοπισμού σφαλμάτων στούντιο και είδαν την decompiled εξόδου x86. Και στις δύο περιπτώσεις, ο κώδικας x86 ήταν ίδια, με την εξαίρεση των ονομάτων τάξης και διευθύνσεις μνήμης λειτουργίας (η οποία φυσικά θα πρέπει να είναι διαφορετική). Εδώ είναι

//            var n = new NormalClass();
00000000  push        ebp 
00000001  mov         ebp,esp 
00000003  sub         esp,8 
00000006  cmp         dword ptr ds:[00585314h],0 
0000000d  je          00000014 
0000000f  call        70032C33 
00000014  xor         edx,edx 
00000016  mov         dword ptr [ebp-4],edx 
00000019  mov         ecx,588230h 
0000001e  call        FFEEEBC0 
00000023  mov         dword ptr [ebp-8],eax 
00000026  mov         ecx,dword ptr [ebp-8] 
00000029  call        dword ptr ds:[00588260h] 
0000002f  mov         eax,dword ptr [ebp-8] 
00000032  mov         dword ptr [ebp-4],eax 
//            n.WriteIt("a string");
00000035  mov         edx,dword ptr ds:[033220DCh] 
0000003b  mov         ecx,dword ptr [ebp-4] 
0000003e  cmp         dword ptr [ecx],ecx 
00000040  call        dword ptr ds:[0058827Ch] 
//        }
00000046  nop 
00000047  mov         esp,ebp 
00000049  pop         ebp 
0000004a  ret 

Σκέφτηκα τότε ίσως τρέχει κάτω από το πρόγραμμα εντοπισμού σφαλμάτων αναγκάζει να εκτελέσει λιγότερο επιθετική βελτιστοποίηση;

Στη συνέχεια έτρεξε ένα αυτόνομο απελευθέρωση χτίσει εκτελέσιμο έξω από οποιοδήποτε περιβάλλον εντοπισμού σφαλμάτων, και να χρησιμοποιηθεί Windbg + SOS για να σπάσει το μετά την ολοκλήρωση του προγράμματος, και να δείτε το dissasembly της ΚΟΕ μεταγλωττισμένο κώδικα x86.

Όπως μπορείτε να δείτε από το παρακάτω κώδικα, όταν τρέχει έξω από το πρόγραμμα εντοπισμού σφαλμάτων ο compiler ΚΟΕ είναι πιο επιθετική, και έχει inlined τη WriteItσταθερή μέθοδο μέσα στην καλούντα. Το κρίσιμο θέμα όμως είναι ότι ήταν πανομοιότυπο όταν καλείτε μια σφραγισμένη έναντι μη σφραγισμένο τάξη. Δεν υπάρχει καμία απολύτως διαφορά ανάμεσα σε ένα σφραγισμένο ή nonsealed τάξη.

Εδώ είναι όταν καλείτε μια κανονική τάξη:

Normal JIT generated code
Begin 003c00b0, size 39
003c00b0 55              push    ebp
003c00b1 8bec            mov     ebp,esp
003c00b3 b994391800      mov     ecx,183994h (MT: ScratchConsoleApplicationFX4.NormalClass)
003c00b8 e8631fdbff      call    00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c00bd e80e70106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00c2 8bc8            mov     ecx,eax
003c00c4 8b1530203003    mov     edx,dword ptr ds:[3302030h] ("NormalClass")
003c00ca 8b01            mov     eax,dword ptr [ecx]
003c00cc 8b403c          mov     eax,dword ptr [eax+3Ch]
003c00cf ff5010          call    dword ptr [eax+10h]
003c00d2 e8f96f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00d7 8bc8            mov     ecx,eax
003c00d9 8b1534203003    mov     edx,dword ptr ds:[3302034h] ("a string")
003c00df 8b01            mov     eax,dword ptr [ecx]
003c00e1 8b403c          mov     eax,dword ptr [eax+3Ch]
003c00e4 ff5010          call    dword ptr [eax+10h]
003c00e7 5d              pop     ebp
003c00e8 c3              ret

Vs σφραγισμένο τάξη:

Normal JIT generated code
Begin 003c0100, size 39
003c0100 55              push    ebp
003c0101 8bec            mov     ebp,esp
003c0103 b90c3a1800      mov     ecx,183A0Ch (MT: ScratchConsoleApplicationFX4.SealedClass)
003c0108 e8131fdbff      call    00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c010d e8be6f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0112 8bc8            mov     ecx,eax
003c0114 8b1538203003    mov     edx,dword ptr ds:[3302038h] ("SealedClass")
003c011a 8b01            mov     eax,dword ptr [ecx]
003c011c 8b403c          mov     eax,dword ptr [eax+3Ch]
003c011f ff5010          call    dword ptr [eax+10h]
003c0122 e8a96f106f      call    mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0127 8bc8            mov     ecx,eax
003c0129 8b1534203003    mov     edx,dword ptr ds:[3302034h] ("a string")
003c012f 8b01            mov     eax,dword ptr [ecx]
003c0131 8b403c          mov     eax,dword ptr [eax+3Ch]
003c0134 ff5010          call    dword ptr [eax+10h]
003c0137 5d              pop     ebp
003c0138 c3              ret

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

Απαντήθηκε 20/02/2012 στις 21:45
πηγή χρήστη

ψήφοι
4

Επισήμανση τάξη sealedθα πρέπει να έχει καμία επίδραση στην απόδοση.

Υπάρχουν περιπτώσεις όπου cscμπορεί να χρειαστεί να εκπέμπει ένα callvirtopcode αντί για ένα callopcode. Ωστόσο, φαίνεται ότι αυτές οι περιπτώσεις είναι σπάνιες.

Και μου φαίνεται ότι η ΚΟΕ θα πρέπει να είναι σε θέση να εκπέμπουν το ίδιο μη-εικονική κλήση της συνάρτησης για callvirtότι κάνατε για call, εάν γνωρίζει ότι η τάξη δεν έχει κανένα υποκατηγορίες (ακόμα). Εάν υπάρχει μόνο μία εφαρμογή της μεθόδου, δεν υπάρχει κανένα σημείο τη φόρτωση διεύθυνσή του από ένα vtable-απλά καλέστε άμεσα το ένα εφαρμογής. Για το θέμα αυτό, η ΚΟΕ μπορεί ακόμη και inline τη λειτουργία.

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

(Και ναι, VM σχεδιαστές πραγματικά επιθετικά επιδιώκουν αυτά τα μικροσκοπικά νίκες απόδοσης.)

Απαντήθηκε 20/11/2009 στις 10:53
πηγή χρήστη

ψήφοι
3

Θεωρώ «σφραγίζονται» τάξεις της κανονικής περίπτωση και πάντα έχουν ένα λόγο να παραλείψετε το «σφραγισμένο» λέξη-κλειδί.

Οι πιο σημαντικοί λόγοι για μένα είναι οι εξής:

α) Καλύτερη κατάρτιση ελέγχους χρόνο (χύτευση με διασυνδέσεις δεν εφαρμοστεί θα πρέπει να ανιχνεύεται κατά τη μεταγλώττιση, όχι μόνο κατά το χρόνο εκτέλεσης)

και, πάνω λόγο:

β) Κατάχρηση τάξεις μου δεν είναι δυνατόν με αυτόν τον τρόπο

Εύχομαι η Microsoft θα κάνει «σφραγίζεται» το πρότυπο, δεν «ασφράγιστο».

Απαντήθηκε 03/08/2010 στις 15:27
πηγή χρήστη

ψήφοι
3

<Εκτός θέματος, αλαζονικό>

Θα σιχαίνομαι σφραγισμένο τάξεις. Ακόμη και αν τα οφέλη απόδοσης είναι εκπληκτική (που αμφιβάλλω), θα καταστρέψει το μοντέλο object-oriented εμποδίζοντας την επαναχρησιμοποίηση μέσω της κληρονομικότητας. Για παράδειγμα, η κατηγορία Νήμα σφραγίζεται. Αν και βλέπω ότι θα μπορούσε κανείς να θέλουν τα θέματα να είναι όσο το δυνατόν πιο αποτελεσματική, μπορώ επίσης να φανταστεί σενάρια όπου είναι σε θέση να υποκατηγορία Νήμα θα έχει μεγάλα οφέλη. Συγγραφείς Class, αν πρέπει να σφραγίσει τις τάξεις σας για λόγους «απόδοση», δώστε μια διεπαφή τουλάχιστον έτσι δεν έχουμε να τυλίξει και αντικατάσταση παντού ότι χρειαζόμαστε ένα χαρακτηριστικό έχετε ξεχάσει.

Παράδειγμα: SafeThread έπρεπε να τυλίξει την τάξη Νήμα επειδή Thread σφραγίζεται και δεν υπάρχει διεπαφή IThread? SafeThread παγιδεύει αυτόματα unhandled εξαιρέσεις για τα θέματα, κάτι εντελώς λείπει από την τάξη Θέματος. [και όχι, οι ανεπίλυτη γεγονότα εξαίρεση δεν δεν πάρει unhandled εξαιρέσεις στη δευτεροβάθμια θέματα].

</ Εκτός θέματος, αλαζονικό>

Απαντήθηκε 14/10/2008 στις 21:04
πηγή χρήστη

ψήφοι
3

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

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

Απαντήθηκε 05/08/2008 στις 13:37
πηγή χρήστη

ψήφοι
2

σφραγισμένο μαθήματα θα είναι τουλάχιστον ένα μικροσκοπικό λίγο πιο γρήγορα, αλλά μερικές φορές μπορεί να είναι waayyy πιο γρήγορα ... αν το Optimizer ΚΟΕ μπορεί inline κλήσεις που θα έχουν διαφορετικά ήταν εικονικές κλήσεις. Έτσι, όπου υπάρχει συχνά αποκαλούμενες μεθόδους που είναι αρκετά μικρή για να inlined, σίγουρα εξετάσει τη σφράγιση την τάξη.

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

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

Απαντήθηκε 01/10/2011 στις 11:37
πηγή χρήστη

ψήφοι
2

@Vaibhav, τι είδους εξετάσεις δεν θα εκτελέσει τη μέτρηση των επιδόσεων;

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

SSCLI (ρότορα)
SSCLI: Υποδομές Shared Source κοινής γλώσσας

Η Υποδομή κοινής γλώσσας (CLI) είναι το πρότυπο ECMA που περιγράφει τον πυρήνα του .NET Framework. Η Shared Source CLI (SSCLI), επίσης γνωστό ως Δρομέας, είναι ένα συμπιεσμένο αρχείο του πηγαίου κώδικα σε μια εφαρμογή εργασίας του ECMA CLI και την ECMA C προδιαγραφές # γλώσσας, τεχνολογίες στην καρδιά της ΝΕΤ αρχιτεκτονικής της Microsoft.

Απαντήθηκε 05/08/2008 στις 13:40
πηγή χρήστη

ψήφοι
-9

Εκτέλεση αυτού του κώδικα και θα δείτε ότι σφραγίζονται τα μαθήματα είναι 2 φορές πιο γρήγορα:

class Program
{
    static void Main(string[] args)
    {
        Console.ReadLine();

        var watch = new Stopwatch();
        watch.Start();
        for (int i = 0; i < 10000000; i++)
        {
            new SealedClass().GetName();
        }
        watch.Stop();
        Console.WriteLine("Sealed class : {0}", watch.Elapsed.ToString());

        watch.Start();
        for (int i = 0; i < 10000000; i++)
        {
            new NonSealedClass().GetName();
        }
        watch.Stop();
        Console.WriteLine("NonSealed class : {0}", watch.Elapsed.ToString());

        Console.ReadKey();
    }
}

sealed class SealedClass
{
    public string GetName()
    {
        return "SealedClass";
    }
}

class NonSealedClass
{
    public string GetName()
    {
        return "NonSealedClass";
    }
}

εξόδου: Σφραγισμένο κατηγορία: 00: 00: 00,1897568 NonSealed κατηγορία: 00: 00: 00,3826678

Απαντήθηκε 26/11/2009 στις 18:50
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more