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:
System.OutOfMemoryExceptionOtros 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.
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:
dotnet publish -c Release -r win-x64dotnet publish -c Release -r win-x64O fija el objetivo directamente en tu .csproj:
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup><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.
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.
¿Aún desplazándote?
¿Quieres una prueba rápida? PM > Install-Package IronOcr
ejecuta una muestra y observa cómo tu imagen se convierte en texto buscable.
Comience gratis
Comience gratis
Reserve demostración en vivo gratis
No se requiere tarjeta de crédito ni creación de cuenta
