# 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:
```txt
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ą.
[[i:(IronOCR także wywołuje natywne biblioteki dla OCR, renderowania obrazów i rasteryzacji PDF.) Te zmieniają niezarządzaną pamięć, której kolektor śmieci .NET nie widzi, co jeszcze bardziej zwiększa presję w procesie 32-bitowym.
)]]
## Rozwiązanie
### Opcja 1: Ustaw cel platformy w Visual Studio
Przełącz projekt na x64 przez ustawienia kompilacji:
1. Kliknij prawym przyciskiem myszy na swoim projekcie i otwórz **Właściwości**.
2. Otwórz kartę **Kompilacja**.
3. Ustaw **Cel platformy** na `x64`.
4. Pozostaw **Preferuj 32-bit** niezaznaczone.
### Opcja 2: Ustaw cel z CLI lub .csproj
Publikuj w 64-bitowym środowisku wykonawczym, aby wymusić architekturę podczas kompilacji:
```bash
dotnet publish -c Release -r win-x64
```
Lub przypnij cel bezpośrednio w swoim `.csproj`:
```xml
<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.
[[w:(Unikaj "AnyCPU" z opcją "Preferuj 32-bit" włączoną. Cicho reintrodukuje to limit 2GB nawet na maszynie 64-bitowej.)]]
## 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.
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
System.OutOfMemoryException
Text
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ą.
Zwróć uwagę: IronOCR także wywołuje natywne biblioteki dla OCR, renderowania obrazów i rasteryzacji PDF.) Te zmieniają niezarządzaną pamięć, której kolektor śmieci .NET nie widzi, co jeszcze bardziej zwiększa presję w procesie 32-bitowym.
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:
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.
Ostrzeżenie: Unikaj "AnyCPU" z opcją "Preferuj 32-bit" włączoną. Cicho reintrodukuje to limit 2GB nawet na maszynie 64-bitowej.
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.
Curtis Chau posiada tytuł licencjata z informatyki (Uniwersytet Carleton) i specjalizuje się w front-endowym rozwoju, z ekspertką w Node.js, TypeScript, JavaScript i React. Pasjonuje się tworzeniem intuicyjnych i estetycznie przyjemnych interfejsów użytkownika, Curtis cieszy się pracą z nowoczesnymi frameworkami i tworzeniem dobrze zorganizowanych, atrakcyjnych wizualnie podręczników.
