Wie viel schneller ist die native Implementierung der systemeigenen kryptografischen Hashes unter Windows als die .Net Managed-Version?
Ich stelle Hashes für Datenmengen zur Verfügung, um die Daten zu identifizieren und sie durch Hash zu identifizieren - dies ist der Hauptanwendungsfall für schnelle Hashes wie SHA1 und MD5.
In .Net gibt es eine Option, um mit den nativen oder verwalteten Implementierungen einiger dieser Hashes (die SHA-Varianten sowieso) zu gehen. Ich suche nach einer verwalteten MD5-Implementierung, und es scheint keine im .Net-Framework zu sein, aber ich frage mich, ob der umschlossene native CSP sowieso schneller ist, und wenn ich nur Inhalt verwenden sollte, dass es keine Perf Probleme bei der Verwendung. Die beste Antwort auf Warum gibt es keine? Managed MD5-Implementierung im .NET-Framework? zeigt an, dass eine schnellere Performance der Grund dafür sein könnte, dass eine verwaltete Variante nicht existiert.
Stimmt das, und wenn ja, wie viel schneller ist der native CSP?
1 Antwort
Leider ist der eingebundene native CSP für MD5 - MD5CryptoServiceProvider - wesentlich langsamer als eine reine verwaltete Implementierung. Es ist ein hartnäckiger Standpunkt, der besagt, dass nativer Code eindeutig schneller ist als verwalteter Code: In vielen Fällen ist das Gegenteil der Fall. Dies ist zumindest bei Kopf-an-Kopf-Messungen der Fall.
Unter Verwendung der übersetzten Referenz-MD5-Implementierung von David Anson habe ich ein schneller Leistungstest ( Quelle ), die darauf abzielt, große Leistungsunterschiede zwischen den beiden Implementierungen zu messen. Während bei kleinen Datenfeldern der Unterschied erwartungsgemäß bei etwa 16kB vernachlässigbar ist, zeigt die native Implementierung möglicherweise eine signifikante Verzögerung - in der Größenordnung von Millisekunden. Dies scheint nicht viel, aber es ist Größenordnungen langsamer als die reine verwaltete Implementierung. Dieser Unterschied wird beibehalten, wenn die Größe der Daten, die gehashed werden, zunimmt, und bei dem größten getesteten Datenarray von ~ 250 MB betrug der Unterschied in der CPU-Zeit etwa 8,5 Sekunden. Wenn man bedenkt, dass ein Hash wie dieser oft verwendet wird, um sehr große Dateien abzufragen, würde sich diese zusätzliche Verzögerung bemerkbar machen, selbst gegenüber den oft viel größeren Verzögerungen durch I / O.
Es ist nicht sehr klar, wo die Verzögerung herkommt, da ein reiner nativer Test nicht durchgeführt wurde (einer, der auf die Umhüllung eines CSP und den Verbrauch in verwaltetem Code verzichtet), aber angesichts der nahezu identischen Form der Graphen auf der Bei der Protokollskalierung scheint es so zu sein, dass die verwalteten und systemeigenen Implementierungen die gleiche systemimmanente Leistung aufweisen, die Leistung des nativen Codes jedoch aufgrund der Kosten der Interoperabilität zwischen nativem und verwaltetem Code zur Laufzeit in der Leistung "verschoben" wird. Dieser Leistungsunterschied zwischen umgebrochenen nativen CSPs und reinen verwalteten Implementierungen wurde ebenfalls behoben reproduziert und dokumentiert von anderen Ermittlern .
Zusätzlich zur Beantwortung der Frage "Wie viel schneller ist die native Implementierung" in diesem speziellen Fall, hoffe ich, dass dieses Beweismaterial zur Eingabeaufforderung dient mehr Reflexion und Untersuchung wenn die Frage nach nativ vs. gemanaged auftaucht, bricht die althergebrachte und schädliche Reaktion auf ähnliche Fragen, dass nativer Code immer schneller und damit irgendwie besser ist. Der verwaltete Code ist selbst in dieser performance-sensitiven Domäne des Massendatenhashings eindeutig sehr schnell.
Tags und Links .net performance native md5 sha