?

Der Grund warum deine Lösung so langsam ist, ist die Verwendung des += Operators zum Anfügen.
Strings sind immutable. Das bedeutet, dass ein String-Object niemals geändert wird.
Bei jedem Modifizeren wird jedesmal ein neuer String erstellt. Das bedeutet jedes mal eine Allokation des Speichers + rüberkopieren.
Damit erhältst du eine Komplexität von n^2.

Mit einem Stringbuilder kannst du vorher genug Platz (capacity) reservieren, damit nie realloziiert werden muss.
Dann haste auch wieder die Komplexität von n.

Chr(13) ist übrigens Müll, weil
1. es kein Mesch lesen kann. Es Code sollte auch für den Menschen lesbar sein und nicht nur für die Maschine! Es gibt immer Alternativen z.B. Environment.NewLine.
2. die Funktion kommt aus dem VisualBasic-Namespace.

Wenn es auf Geschwindigkeit ankommt, würde ich die Datei mit einem FileStream öffnen und diesen Bytewiese mit der Read-Funktion in einen StringBuilder schreiben, der mit der Stream-Länge*3 (oder *4, je nach Zeilenumbruch) initialisiert wurde.
Verbraucht rund 1/3 weniger RAM, ist schneller und abwärtskompatibeler als die LINQ-Version+die ganze Datei in den RAM laden.

@Andy16823:: Du bist Dir offensichtlich nicht über folgendes klar:
Hex ist nicht ein anderer Typ von Zahl, sondern lediglich eine andere Schreibweise dieser Zahl.
Wenn Du eine Zahl in ihrer Hex-Darstellung in einem Label oder einer Textbox oder so ausgeben willst, ist dies die Stringrepräsentation dieser Zahl, z.B FF für 255.
In den Quellcode schreibst Du Hex-Zahlen mit einem "&H" davor, also &HFF (VB) bzw. 0xFF (C, C++, C#).
Der Wert dieser Zahl hat sich dabei nicht geändert.
Es ist genau so, als wenn Du ein Datum anders formatierst, z.B. 15.2.14 oder 15.02.2014 oder 2014-01-15 usw., es bezeichnet immer denselben Tag.