Zawsze używaj architektury 64-bitowej z IronOCR
IronOCR wykonuje pod spodem pracę wymagającą dużo pamięci, więc build 32-bitowy (x86) osiąga limit pamięci ~2 GB i zaczyna nie działać przy dużych lub dużej liczbie dokumentów. Celowanie w 64-bitową (x64) jest rozwiązaniem.
Proces 32-bitowy jest ograniczony do około 2 GB użytecznej pamięci niezależnie od tego, ile RAMu ma maszyna. Pod tym limitem prace OCR często przebijają się jako:
System.OutOfMemoryException
Inne objawy tego samego limitu to zakleszczenia podczas wykonywania silnika OCR, brak zasobów w preprocessing obrazów, awarie lub nieobsługiwane wyjątki, oraz wyniki OCR, które kończą się niepowodzeniem w milczeniu.
Presja wynika z operacji, które IronOCR wykonuje na dokument: renderowanie obrazu w wysokiej rozdzielczości, tymczasowa rasteryzacja, optyczne rozpoznawanie znaków oraz głęboka ekstrakcja tekstu za pomocą modelu uczenia maszynowego (używana przez metody AdvancedScan i wyjście SearchablePDF). Każda z nich może wymagać setek MB na dokument, a wielostronicowe PDFy, wielostronicowe TIFFy i obrazy o DPI 300+ jeszcze to podnoszą.
Rozwiązanie
Opcja 1: Ustaw cel platformy w Visual Studio
Przełącz projekt na x64 przez ustawienia kompilacji:
- Kliknij prawym przyciskiem myszy na swoim projekcie i otwórz Właściwości.
- Otwórz kartę Kompilacja.
- Ustaw Cel platformy na
x64. - Pozostaw Preferuj 32-bit niezaznaczone.
Opcja 2: Ustaw cel z CLI lub .csproj
Publikuj w 64-bitowym środowisku wykonawczym, aby wymusić architekturę podczas kompilacji:
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
Lub przypnij cel bezpośrednio w swoim .csproj:
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
Linia <Prefer32Bit>false</Prefer32Bit> ma znaczenie, gdy projekt jest AnyCPU: z tym włączonym, aplikacja wciąż uruchamia się jako 32-bitowy proces i dziedziczy ten sam limit.
Kiedy podejrzewać architekturę
Sprawdź architekturę najpierw, jeśli zauważysz przestój lub awarię zadań OCR, nieoczekiwane wyjątki out-of-memory lub pogorszenie wydajności na dokumentach o dużej liczbie. Jeśli korzystasz z x86, przełącz się na x64 przed zbadaniem czegokolwiek innego.
Upewnij się, że kilka nawyków zostanie utrzymanych w produkcji:
- Cel x64 dla produkcji: to jedyna obsługiwana konfiguracja dla ciężkich zadań OCR.
- Rozwijanie na x64: testowanie na x64 odzwierciedla rzeczywiste zachowanie pamięci i ujawnia problemy na wczesnym etapie.
- Budowanie 64-bitowych obrazów Docker: upewnij się, że obraz podstawowy to
linux/amd64.
Zauważ, że jednoczesne zadania OCR szybko zwiększają użycie pamięci. Nawet przy małych dokumentach, operacje wielowątkowe lub asynchroniczne mogą rosnąć szybko.
Jeśli nie możesz zmienić architektury
Gdy x64 nie jest opcją, rozbij duże dokumenty na mniejsze kawałki i przetwarzaj przy niższej rozdzielczości. Oczekuj kompromisu między wydajnością a dokładnością. Trwa badanie stabilnego wsparcia dla projektów 32-bitowych.

