# Utilisez toujours l'architecture 64 bits avec IronOCR
IronOCR effectue un travail gourmand en mémoire sous le capot, donc une construction 32 bits (x86) atteint la limite de mémoire de ~2 Go et commence à échouer sur des documents volumineux ou à haut débit. Cibler le 64 bits (x64) est la solution.
Un processus 32 bits est limité à environ 2 Go de mémoire utilisable, peu importe la quantité de RAM dont dispose la machine. Sous ce seuil, le travail OCR apparaît communément comme :
```txt
System.OutOfMemoryException
```
D'autres symptômes du même seuil incluent des blocages pendant l'exécution du moteur OCR, une pénurie de ressources lors du prétraitement de l'image, des plantages ou des exceptions non gérées, et des résultats OCR qui expirent ou échouent silencieusement.
La pression provient des opérations qu'IronOCR effectue par document : rendu d'image haute résolution, rasterisation temporaire, reconnaissance optique de caractères et extraction profonde de texte utilisant un modèle d'apprentissage automatique (utilisé par les méthodes `AdvancedScan` et la sortie `SearchablePDF`). Chacune de ces opérations peut exiger des centaines de Mo par document, et les PDFs multi-pages, TIFFs multi-pages, et images 300+ DPI poussent cela plus haut.
[[i:(IronOCR appelle également des bibliothèques natives pour l'OCR, le rendu d'images et la rasterisation PDF. Celles-ci allouent de la mémoire non gérée que le ramasse-miettes .NET ne peut voir, ce qui ajoute encore plus de pression dans un processus 32 bits.)]]
## Solution
### Option 1 : Définir la cible de plateforme dans Visual Studio
Passez le projet à x64 à travers les paramètres de construction :
1. Faites un clic droit sur votre projet et ouvrez **Propriétés**.
2. Ouvrez l'onglet **Build**.
3. Réglez **Cible de plateforme** sur `x64`.
4. Laissez **Préférer 32 bits** décoché.
### Option 2 : Définir la cible à partir du CLI ou du .csproj
Publiez contre un runtime 64 bits pour imposer l'architecture au moment de la construction :
```bash
dotnet publish -c Release -r win-x64
```
Ou épinglez directement la cible dans votre `.csproj` :
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
La ligne `<Prefer32Bit>false</Prefer32Bit>` est importante lorsque le projet est `AnyCPU` : avec elle activée, l'application se lance toujours en tant que processus 32 bits et hérite de la même limite.
[[w:(Évitez "AnytCPU" avec "Préférer 32 bits" activé.)]] Cela réintroduit silencieusement la limite de 2 Go même sur une machine 64 bits.)
)}]
## Quand soupçonner l'architecture
Vérifiez d'abord l'architecture si vous voyez des tâches OCR bloquer ou se bloquer de manière inattendue, des exceptions de mémoire insuffisante intermittentes ou une dégradation des performances sur des documents volumineux. Si vous utilisez x86, passez à x64 avant d'examiner quoi que ce soit d'autre.
Gardez quelques habitudes en prod :
- **Cible x64 pour la production :** c'est la seule configuration supportée pour des charges de travail OCR lourdes.
- **Développez sur x64 :** les tests sur x64 reflètent le comportement mémoire réel et identifient les problèmes tôt.
- **Construisez des images Docker 64 bits :** assurez-vous que l'image de base est `linux/amd64`.
Notez que le travail OCR simultané augmente rapidement la mémoire. Même avec de petits documents, les opérations multithread ou asynchrones peuvent grimper rapidement.
## Si vous ne pouvez pas changer d'architecture
Lorsque x64 n'est pas une option, divisez les gros documents en plus petits morceaux et traitez à une résolution plus basse. Attendez-vous à un compromis en termes de performance et de précision. Le support stable des projets 32 bits est actuellement en cours d'examen.
IronOCR effectue un travail gourmand en mémoire sous le capot, donc une construction 32 bits (x86) atteint la limite de mémoire de ~2 Go et commence à échouer sur des documents volumineux ou à haut débit. Cibler le 64 bits (x64) est la solution.
Un processus 32 bits est limité à environ 2 Go de mémoire utilisable, peu importe la quantité de RAM dont dispose la machine. Sous ce seuil, le travail OCR apparaît communément comme :
System.OutOfMemoryException
System.OutOfMemoryException
Text
D'autres symptômes du même seuil incluent des blocages pendant l'exécution du moteur OCR, une pénurie de ressources lors du prétraitement de l'image, des plantages ou des exceptions non gérées, et des résultats OCR qui expirent ou échouent silencieusement.
La pression provient des opérations qu'IronOCR effectue par document : rendu d'image haute résolution, rasterisation temporaire, reconnaissance optique de caractères et extraction profonde de texte utilisant un modèle d'apprentissage automatique (utilisé par les méthodes AdvancedScan et la sortie SearchablePDF). Chacune de ces opérations peut exiger des centaines de Mo par document, et les PDFs multi-pages, TIFFs multi-pages, et images 300+ DPI poussent cela plus haut.
Veuillez noter: IronOCR appelle également des bibliothèques natives pour l'OCR, le rendu d'images et la rasterisation PDF. Celles-ci allouent de la mémoire non gérée que le ramasse-miettes .NET ne peut voir, ce qui ajoute encore plus de pression dans un processus 32 bits.
Solution
Option 1 : Définir la cible de plateforme dans Visual Studio
Passez le projet à x64 à travers les paramètres de construction :
Faites un clic droit sur votre projet et ouvrez Propriétés.
Ouvrez l'onglet Build.
Réglez Cible de plateforme sur x64.
Laissez Préférer 32 bits décoché.
Option 2 : Définir la cible à partir du CLI ou du .csproj
Publiez contre un runtime 64 bits pour imposer l'architecture au moment de la construction :
dotnet publish -c Release -r win-x64
dotnet publish -c Release -r win-x64
SHELL
Ou épinglez directement la cible dans votre .csproj :
La ligne <Prefer32Bit>false</Prefer32Bit> est importante lorsque le projet est AnyCPU : avec elle activée, l'application se lance toujours en tant que processus 32 bits et hérite de la même limite.
Avertissement: Évitez "AnytCPU" avec "Préférer 32 bits" activé.
Cela réintroduit silencieusement la limite de 2 Go même sur une machine 64 bits.)
)}]
Quand soupçonner l'architecture
Vérifiez d'abord l'architecture si vous voyez des tâches OCR bloquer ou se bloquer de manière inattendue, des exceptions de mémoire insuffisante intermittentes ou une dégradation des performances sur des documents volumineux. Si vous utilisez x86, passez à x64 avant d'examiner quoi que ce soit d'autre.
Gardez quelques habitudes en prod :
Cible x64 pour la production : c'est la seule configuration supportée pour des charges de travail OCR lourdes.
Développez sur x64 : les tests sur x64 reflètent le comportement mémoire réel et identifient les problèmes tôt.
Construisez des images Docker 64 bits : assurez-vous que l'image de base est linux/amd64.
Notez que le travail OCR simultané augmente rapidement la mémoire. Même avec de petits documents, les opérations multithread ou asynchrones peuvent grimper rapidement.
Si vous ne pouvez pas changer d'architecture
Lorsque x64 n'est pas une option, divisez les gros documents en plus petits morceaux et traitez à une résolution plus basse. Attendez-vous à un compromis en termes de performance et de précision. Le support stable des projets 32 bits est actuellement en cours d'examen.
Curtis Chau détient un baccalauréat en informatique (Université de Carleton) et se spécialise dans le développement front-end avec expertise en Node.js, TypeScript, JavaScript et React. Passionné par la création d'interfaces utilisateur intuitives et esthétiquement plaisantes, Curtis aime travailler avec des frameworks modernes et créer des manuels bien structurés et visuellement attrayants.
