# Usar siempre arquitectura de 64 bits con IronOCR
IronOCR ejecuta trabajos que consumen mucha memoria internamente, por lo que un build de 32 bits (x86) alcanza el límite de ~2GB de memoria y comienza a fallar en documentos grandes o de alto volumen. Apuntar a 64 bits (x64) es la solución.
Un proceso de 32 bits está limitado a aproximadamente 2GB de memoria utilizable, sin importar cuánto RAM tenga la máquina. Bajo ese límite, el trabajo OCR comúnmente se presenta como:
```txt
System.OutOfMemoryException
```
Otros síntomas del mismo límite incluyen bloqueos durante la ejecución del motor OCR, escasez de recursos en el preprocesamiento de imágenes, fallos o excepciones no manejadas, y resultados OCR que se agotan o fallan silenciosamente.
La presión proviene de las operaciones que IronOCR realiza por documento: renderización de imágenes de alta resolución, rasterización temporal, reconocimiento óptico de caracteres, y extracción profunda de texto mediante un modelo de aprendizaje automático (utilizado por los métodos `AdvancedScan` y `SearchablePDF` de salida). Cada una de estas puede exigir cientos de MB por documento, y PDFs de múltiples páginas, TIFFs de múltiples páginas, y imágenes de más de 300 DPI lo empujan hacia arriba.
[[i:(IronOCR también llama a bibliotecas nativas para OCR, renderización de imágenes y rasterización de PDFs. Estas asignan memoria no administrada que el recolector de basura de .NET no puede ver, lo que agrega aún más presión en un proceso de 32 bits.)]]
## Solución
### Opción 1: Configurar el objetivo de la plataforma en Visual Studio
Cambia el proyecto a x64 a través de las configuraciones de compilación:
1. Haz clic derecho en tu proyecto y abre **Propiedades**.
2. Abre la pestaña **Compilación**.
3. Configura **Objetivo de plataforma** en `x64`.
4. Deja **Preferir 32-bit** desmarcado.
### Opción 2: Configurar el objetivo desde el CLI o .csproj
Publica contra un runtime de 64 bits para imponer la arquitectura en tiempo de compilación:
```bash
dotnet publish -c Release -r win-x64
```
O fija el objetivo directamente en tu `.csproj`:
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
La línea `<Prefer32Bit>false</Prefer32Bit>` importa cuando el proyecto está `AnyCPU`: con él habilitado, la aplicación todavía se lanza como un proceso de 32 bits y hereda el mismo límite.
[[w:(Evitar "AnyCPU" con "Prefer 32-bit" habilitado. Silenciosamente reintroduce el límite de 2GB incluso en una máquina de 64 bits.)]]
## Cuándo sospechar de la arquitectura
Revisa la arquitectura primero si observas trabajos OCR detenidos o fallando inesperadamente, excepciones intermitentes por falta de memoria, o degradación del rendimiento en documentos de alto volumen. Si estás ejecutando en x86, cambia a x64 antes de investigar cualquier otra cosa.
Mantén algunos hábitos en producción:
- **Apuntar a x64 para producción:** es la única configuración compatible para cargas de trabajo OCR pesadas.
- **Desarrollar en x64:** las pruebas en x64 reflejan el comportamiento de memoria del mundo real y sacan a la luz problemas temprano.
- **Construir imágenes Docker de 64 bits:** asegúrate de que la imagen base sea `linux/amd64`.
Ten en cuenta que los trabajos OCR concurrentes elevan rápidamente la memoria. Incluso con documentos pequeños, las operaciones multi-thread o asíncronas pueden escalar rápidamente.
## Si no puedes cambiar de arquitectura
Cuando x64 no es una opción, divide los documentos grandes en piezas más pequeñas y procesa a una resolución más baja. Espera una compensación en rendimiento y precisión. Actualmente se está investigando el soporte estable para proyectos de 32 bits.
IronOCR ejecuta trabajos que consumen mucha memoria internamente, por lo que un build de 32 bits (x86) alcanza el límite de ~2GB de memoria y comienza a fallar en documentos grandes o de alto volumen. Apuntar a 64 bits (x64) es la solución.
Un proceso de 32 bits está limitado a aproximadamente 2GB de memoria utilizable, sin importar cuánto RAM tenga la máquina. Bajo ese límite, el trabajo OCR comúnmente se presenta como:
System.OutOfMemoryException
System.OutOfMemoryException
Text
Otros síntomas del mismo límite incluyen bloqueos durante la ejecución del motor OCR, escasez de recursos en el preprocesamiento de imágenes, fallos o excepciones no manejadas, y resultados OCR que se agotan o fallan silenciosamente.
La presión proviene de las operaciones que IronOCR realiza por documento: renderización de imágenes de alta resolución, rasterización temporal, reconocimiento óptico de caracteres, y extracción profunda de texto mediante un modelo de aprendizaje automático (utilizado por los métodos AdvancedScan y SearchablePDF de salida). Cada una de estas puede exigir cientos de MB por documento, y PDFs de múltiples páginas, TIFFs de múltiples páginas, y imágenes de más de 300 DPI lo empujan hacia arriba.
Por favor nota: IronOCR también llama a bibliotecas nativas para OCR, renderización de imágenes y rasterización de PDFs. Estas asignan memoria no administrada que el recolector de basura de .NET no puede ver, lo que agrega aún más presión en un proceso de 32 bits.
Solución
Opción 1: Configurar el objetivo de la plataforma en Visual Studio
Cambia el proyecto a x64 a través de las configuraciones de compilación:
Haz clic derecho en tu proyecto y abre Propiedades.
Abre la pestaña Compilación.
Configura Objetivo de plataforma en x64.
Deja Preferir 32-bit desmarcado.
Opción 2: Configurar el objetivo desde el CLI o .csproj
Publica contra un runtime de 64 bits para imponer la arquitectura en tiempo de compilación:
La línea <Prefer32Bit>false</Prefer32Bit> importa cuando el proyecto está AnyCPU: con él habilitado, la aplicación todavía se lanza como un proceso de 32 bits y hereda el mismo límite.
Advertencia: Evitar "AnyCPU" con "Prefer 32-bit" habilitado. Silenciosamente reintroduce el límite de 2GB incluso en una máquina de 64 bits.
Cuándo sospechar de la arquitectura
Revisa la arquitectura primero si observas trabajos OCR detenidos o fallando inesperadamente, excepciones intermitentes por falta de memoria, o degradación del rendimiento en documentos de alto volumen. Si estás ejecutando en x86, cambia a x64 antes de investigar cualquier otra cosa.
Mantén algunos hábitos en producción:
Apuntar a x64 para producción: es la única configuración compatible para cargas de trabajo OCR pesadas.
Desarrollar en x64: las pruebas en x64 reflejan el comportamiento de memoria del mundo real y sacan a la luz problemas temprano.
Construir imágenes Docker de 64 bits: asegúrate de que la imagen base sea linux/amd64.
Ten en cuenta que los trabajos OCR concurrentes elevan rápidamente la memoria. Incluso con documentos pequeños, las operaciones multi-thread o asíncronas pueden escalar rápidamente.
Si no puedes cambiar de arquitectura
Cuando x64 no es una opción, divide los documentos grandes en piezas más pequeñas y procesa a una resolución más baja. Espera una compensación en rendimiento y precisión. Actualmente se está investigando el soporte estable para proyectos de 32 bits.
Curtis Chau tiene una licenciatura en Ciencias de la Computación (Carleton University) y se especializa en el desarrollo front-end con experiencia en Node.js, TypeScript, JavaScript y React. Apasionado por crear interfaces de usuario intuitivas y estéticamente agradables, disfruta trabajando con frameworks modernos y creando manuales bien estructurados y visualmente atractivos.
