1. IronOCR
  2. Fehlersuche
  3. Verwenden Sie immer die 64-Bit-Architektur mit IronOCR

Verwenden Sie immer die 64-Bit-Architektur mit IronOCR

Curtis Chau
Curtis Chau
Aktualisiert:
This article was translated from English: Does it need improvement?
Translated
View the article in English

IronOCR führt speicherintensive Arbeiten im Hintergrund aus, daher stößt ein 32-Bit (x86)-Build an die ~2GB Speichergrenze und beginnt zu scheitern bei großen oder hochvolumigen Dokumenten. Das Ziel, 64-Bit (x64) einzusetzen, ist die Lösung.

Ein 32-Bit-Prozess ist unabhängig davon, wie viel RAM die Maschine hat, auf etwa 2GB nutzbaren Speicher begrenzt. Unter dieser Grenze tauchen OCR-Arbeiten häufig wie folgt auf:

System.OutOfMemoryException

Andere Symptome der gleichen Grenze sind Deadlocks während der Ausführung der OCR-Engine, Ressourcenverknappung bei der Bildvorverarbeitung, Abstürze oder nicht behandelte Ausnahmen und OCR-Ergebnisse, die time-out sind oder unbemerkt scheitern.

Der Druck kommt von den Operationen, die IronOCR pro Dokument ausführt: hochauflösende Bilddarstellung, temporäre Rastern, optische Zeichenerkennung und tiefe Textextraktion mit einem maschinellen Lernmodell (verwendet von den AdvancedScan-Methoden und SearchablePDF-Ausgabe). Jede davon kann Hunderte von MB pro Dokument verlangen, und mehrseitige PDFs, mehrseitige TIFFs und 300+ DPI-Bilder treiben das nach oben.

Hinweis:IronOCR ruft auch native Bibliotheken für OCR, Bilddarstellung und PDF-Rastern auf. Diese allokieren nicht verwalteten Speicher, den der .NET-Garbage-Collector nicht sehen kann, was noch mehr Druck in einem 32-Bit-Prozess addiert.

Lösung

Option 1: Setzen Sie das Plattformziel in Visual Studio

Wechseln Sie das Projekt auf x64 über die Build-Einstellungen:

  1. Klicken Sie mit der rechten Maustaste auf Ihr Projekt und öffnen Sie Eigenschaften.
  2. Öffnen Sie die Registerkarte Build.
  3. Setzen Sie Plattformziel auf x64.
  4. Lassen Sie Bevorzugen 32-Bit deaktiviert.

Option 2: Setzen Sie das Ziel über die CLI oder .csproj

Veröffentlichen Sie gegen eine 64-Bit-Laufzeit, um die Architektur zur Build-Zeit zu erzwingen:

dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
SHELL

Oder pinnen Sie das Ziel direkt in Ihrem .csproj fest:

<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
XML

Die <Prefer32Bit>false</Prefer32Bit>-Zeile spielt eine Rolle, wenn das Projekt AnyCPU ist: mit ihr aktiviert, startet die App trotzdem als 32-Bit-Prozess und übernimmt die gleiche Grenze.

WarnungVermeiden Sie "AnyCPU" mit "Bevorzugen 32-Bit" aktiviert. Es führt stillschweigend die 2GB-Beschränkung wieder ein, selbst auf einer 64-Bit-Maschine.

Wann die Architektur verdächtigt werden soll

Überprüfen Sie die Architektur zuerst, wenn Sie OCR-Jobs sehen, die hängen oder unerwartet abstürzen, intermittierende Speicherplatz-Ausnahmen oder Leistungsabbau bei hochvolumigen Dokumenten. Wenn Sie auf x86 laufen, wechseln Sie zu x64, bevor Sie etwas anderes untersuchen.

Behalten Sie einige Gewohnheiten in der Produktion:

  • Ziel auf x64 für die Produktion: es ist die einzige unterstützte Konfiguration für schwere OCR-Arbeitslasten.
  • Entwickeln Sie auf x64: Tests auf x64 spiegeln reales Speicherverhalten wider und bringen Probleme frühzeitig ans Licht.
  • 64-Bit Docker-Images erstellen: Stellen Sie sicher, dass das Basis-Image linux/amd64 ist.

Beachten Sie, dass gleichzeitige OCR-Vorgänge den Speicher schnell ansteigen lassen. Auch bei kleinen Dokumenten können Multithread- oder asynchrone Operationen schnell ansteigen.

Wenn Sie die Architektur nicht ändern können

Wenn x64 keine Option ist, teilen Sie große Dokumente in kleinere Abschnitte auf und verarbeiten Sie sie mit niedrigerer Auflösung. Erwarten Sie einen Kompromiss bei Leistung und Genauigkeit. Stabile Unterstützung für 32-Bit-Projekte wird derzeit untersucht.

Curtis Chau
Curtis Chau
  Jetzt mit dem Ingenieurteam chatten
Technischer Autor

Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender ...

Weiterlesen
Bereit anzufangen?
Nuget Downloads 6,136,090 | Version: 2026.7 gerade veröffentlicht
Still Scrolling Icon

Scrollst du immer noch?

Sie brauchen schnell einen Beweis? PM > Install-Package IronOcr
Führen Sie ein Beispiel aus und beobachten Sie, wie Ihr Bild zu durchsuchbarem Text wird.