# Sempre Use Arquitetura 64 Bits com IronOCR
IronOCR executa trabalho intensivo de memória nos bastidores, então uma construção 32 bits (x86) atinge o limite de memória ~2GB e começa a falhar em documentos grandes ou de alto volume. Direcionar para 64 bits (x64) é a correção.
Um processo de 32 bits é limitado a cerca de 2GB de memória utilizável, independentemente do quanto de RAM a máquina possua. Dentro desse limite, o trabalho de OCR frequentemente se manifesta como:
```txt
System.OutOfMemoryException
```
Outros sintomas do mesmo limite incluem deadlocks durante a execução do motor OCR, escassez de recursos no pré-processamento de imagem, falhas ou exceções não tratadas e resultados do OCR que expiram ou falham silenciosamente.
A pressão vem das operações que o IronOCR executa por documento: renderização de imagem em alta resolução, rasterização temporária, reconhecimento óptico de caracteres e extração profunda de texto usando um modelo de aprendizado de máquina (usado pelos métodos `AdvancedScan` e saída `SearchablePDF`). Cada um desses pode exigir centenas de MB por documento, e PDFs de múltiplas páginas, TIFFs de múltiplas páginas e imagens de 300+ DPI empurram isso ainda mais alto.
[[i:(IronOCR também chama bibliotecas nativas para OCR, renderização de imagem e rasterização de PDF. Esses alocam memória não gerenciada que o coletor de lixo do .NET não pode ver, o que adiciona ainda mais pressão em um processo de 32 bits.)]]
## Solução
### Opção 1: Defina o alvo da plataforma no Visual Studio
Altere o projeto para x64 através das configurações de construção:
1. Clique com o botão direito no seu projeto e abra **Propriedades**.
2. Abra a aba **Compilação**.
2. Defina **Plataforma alvo** como `x64`.
3. Deixe **Preferir 32-bit** desmarcado.
### Opção 2: Defina o alvo do CLI ou no .csproj
Publique contra um runtime de 64 bits para impor a arquitetura no momento da construção:
```bash
dotnet publish -c Release -r win-x64
```
Ou fixe o alvo diretamente no seu `.csproj`:
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
A linha `<Prefer32Bit>false</Prefer32Bit>` importa quando o projeto está `AnyCPU`: com ela habilitada, o aplicativo ainda inicia como um processo de 32-bits e herda o mesmo limite.
[[w:(Evite "AnyCPU" com "Preferir 32-bit" habilitado. Reintroduz silenciosamente o limite de 2GB mesmo em uma máquina de 64 bits.)]]
## Quando Suspeitar da Arquitetura
Verifique primeiro a arquitetura se você perceber que trabalhos OCR estão parando ou falhando inesperadamente, exceções de falta de memória intermitentes, ou degradação de desempenho em documentos de alto volume. Se você estiver operando em x86, mude para x64 antes de investigar qualquer outra coisa.
Mantenha alguns hábitos na produção:
- **Alvo x64 para produção:** é a única configuração suportada para cargas de trabalho de OCR pesadas.
- **Desenvolva em x64:** testar em x64 espelha o comportamento real de memória e revela problemas cedo.
- **Construa imagens Docker de 64 bits:** certifique-se de que a imagem base seja `linux/amd64`.
Observe que o trabalho concorrente de OCR eleva a memória rapidamente. Mesmo com documentos pequenos, operações multithreaded ou assíncronas podem escalar rapidamente.
## Se Você Não Pode Mudar a Arquitetura
Quando x64 não é uma opção, divida documentos grandes em partes menores e processe em uma resolução mais baixa. Espere uma troca de desempenho e precisão. Suporte estável para projetos de 32 bits está atualmente em investigação.
IronOCR executa trabalho intensivo de memória nos bastidores, então uma construção 32 bits (x86) atinge o limite de memória ~2GB e começa a falhar em documentos grandes ou de alto volume. Direcionar para 64 bits (x64) é a correção.
Um processo de 32 bits é limitado a cerca de 2GB de memória utilizável, independentemente do quanto de RAM a máquina possua. Dentro desse limite, o trabalho de OCR frequentemente se manifesta como:
System.OutOfMemoryException
System.OutOfMemoryException
Text
Outros sintomas do mesmo limite incluem deadlocks durante a execução do motor OCR, escassez de recursos no pré-processamento de imagem, falhas ou exceções não tratadas e resultados do OCR que expiram ou falham silenciosamente.
A pressão vem das operações que o IronOCR executa por documento: renderização de imagem em alta resolução, rasterização temporária, reconhecimento óptico de caracteres e extração profunda de texto usando um modelo de aprendizado de máquina (usado pelos métodos AdvancedScan e saída SearchablePDF). Cada um desses pode exigir centenas de MB por documento, e PDFs de múltiplas páginas, TIFFs de múltiplas páginas e imagens de 300+ DPI empurram isso ainda mais alto.
Observe: IronOCR também chama bibliotecas nativas para OCR, renderização de imagem e rasterização de PDF. Esses alocam memória não gerenciada que o coletor de lixo do .NET não pode ver, o que adiciona ainda mais pressão em um processo de 32 bits.
Solução
Opção 1: Defina o alvo da plataforma no Visual Studio
Altere o projeto para x64 através das configurações de construção:
Clique com o botão direito no seu projeto e abra Propriedades.
Abra a aba Compilação.
Defina Plataforma alvo como x64.
Deixe Preferir 32-bit desmarcado.
Opção 2: Defina o alvo do CLI ou no .csproj
Publique contra um runtime de 64 bits para impor a arquitetura no momento da construção:
A linha <Prefer32Bit>false</Prefer32Bit> importa quando o projeto está AnyCPU: com ela habilitada, o aplicativo ainda inicia como um processo de 32-bits e herda o mesmo limite.
Aviso: Evite "AnyCPU" com "Preferir 32-bit" habilitado. Reintroduz silenciosamente o limite de 2GB mesmo em uma máquina de 64 bits.
Quando Suspeitar da Arquitetura
Verifique primeiro a arquitetura se você perceber que trabalhos OCR estão parando ou falhando inesperadamente, exceções de falta de memória intermitentes, ou degradação de desempenho em documentos de alto volume. Se você estiver operando em x86, mude para x64 antes de investigar qualquer outra coisa.
Mantenha alguns hábitos na produção:
Alvo x64 para produção: é a única configuração suportada para cargas de trabalho de OCR pesadas.
Desenvolva em x64: testar em x64 espelha o comportamento real de memória e revela problemas cedo.
Construa imagens Docker de 64 bits: certifique-se de que a imagem base seja linux/amd64.
Observe que o trabalho concorrente de OCR eleva a memória rapidamente. Mesmo com documentos pequenos, operações multithreaded ou assíncronas podem escalar rapidamente.
Se Você Não Pode Mudar a Arquitetura
Quando x64 não é uma opção, divida documentos grandes em partes menores e processe em uma resolução mais baixa. Espere uma troca de desempenho e precisão. Suporte estável para projetos de 32 bits está atualmente em investigação.
Curtis Chau é bacharel em Ciência da Computação (Universidade Carleton) e se especializa em desenvolvimento front-end, com experiência em Node.js, TypeScript, JavaScript e React. Apaixonado por criar interfaces de usuário intuitivas e esteticamente agradáveis, Curtis gosta de trabalhar com frameworks modernos e criar manuais bem estruturados e visualmente atraentes.
