# IronOCR İle Her Zaman 64-Bit Mimarisi Kullanın
IronOCR çok miktarda bellek gerektiren işlemleri arka planda çalıştırır, bu yüzden bir 32 bitlik (x86) yapı, ~2GB bellek tavanına ulaşır ve büyük veya yoğun belgelerde başarısız olur. 64-bit'i (x64) hedeflemek çözümü sağlar.
32-bit bir işlem, makinenin ne kadar RAM'i olursa olsun yaklaşık 2GB kullanılabilir bellekle sınırlandırılmıştır. Bu limit altında, OCR çalışmaları genellikle şu şekilde yüzeye çıkar:
```txt
System.OutOfMemoryException
```
Aynı tavanın diğer belirtileri arasında, OCR motoru çalıştırılırken kilitlenmeler, görüntü ön işleme sırasında kaynak yetersizliği, çökmeler veya işlenmeyen istisnalar ve sessizce başarısız olan veya süre aşımına uğrayan OCR sonuçları yer alır.
Baskı, IronOCR'un her belge üzerinde gerçekleştirdiği işlemlerden gelir: yüksek çözünürlüklü görüntü oluşturma, geçici rasterleştirme, optik karakter tanıma ve makine öğrenme modeli kullanan derin metin çıkarımı (`AdvancedScan` yöntemleri ve `SearchablePDF` çıktısı tarafından kullanılır). Bunlardan her biri belge başına yüzlerce MB gerektirebilir ve çok sayfalı PDF'ler, çok sayfalı TIFF'ler ve 300 + DPI görüntüler bu ihtiyacı daha da artırır.
[[i:(IronOCR ayrıca OCR, görüntü işleme ve PDF rasterleme için yerel kütüphaneleri çağırır. Bunlar, .NET çöp toplayıcının göremediği yönetilmeyen bellek atarlar, bu da zaten 32 bitlik bir işlemede baskıyı daha da artırır.)]]
## Çözüm
### Seçenek 1: Visual Studio'da platform hedefini ayarlayın
Projeyi x64 ile değiştirin ve yapı ayarları aracılığıyla:
1. Projenize sağ tıklayın ve **Özellikler**i açın.
2. **Build** sekmesini açın.
3. **Platform hedefi** olarak `x64` ayarlayın.
4. **32 bit tercih et** işaretli bırakmayın.
### Seçenek 2: Hedefi CLI veya .csproj dosyasından ayarlayın
Ayrıca 64-bit çalışma zamanı arşivini hedefleyerek mimariyi zorlayıcı olarak arşivleyebilirsiniz:
```bash
dotnet publish -c Release -r win-x64
```
Veya hedefi doğrudan `.csproj` içine sabitleyin:
```xml
<PropertyGroup>
<PlatformTarget>x64</PlatformTarget>
<Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>
```
Proje `AnyCPU` olduğunda `<Prefer32Bit>false</Prefer32Bit>` satırı önemlidir: bu etkinleştirilmişse, uygulama hala 32-bit bir işlem olarak başlatılır ve aynı tavanı devralır.
[[w:(32-bit'in tercih edildiği 'AnyCPU'yu kullanmaktan kaçının. Bu sessizce 2GB sınırını, 64-bit bir makinede yeniden tanıtır.)]]
## Mimariyi Ne Zaman Şüphelenmeli?
Eğer OCR çalışmaları aniden duraklıyor veya çöküyorsa, aralıklı bellek yetersizlik hataları veya yüksek hacimli belgelerde performans kaybı yaşıyorsanız, önce mimariyi kontrol edin. Eğer x86 çalışıyorsanız, başka bir şey incelemeden önce x64'e geçin.
Üretimde birkaç alışkanlık edinin:
- **Üretim İçin x64 Hedefleyin:** ağır OCR iş yükleri için tek desteklenen yapılandırmadır.
- **x64 Üzerinde Geliştirin:** x64 üzerinde test yapmak gerçek dünya bellek davranışını yansıtır ve sorunları erken tespit eder.
- **64-bit Docker görüntüleri oluşturun:** ana görüntünün `linux/amd64` olduğundan emin olun.
Unutmayın ki eş zamanlı OCR çalışmaları hafızayı hızla yükseltir. Küçük belgelerde bile, çok iş parçacıklı veya asenkron işlemler hızla tırmanabilir.
## Mimariyi Değiştiremezseniz Ne Yapmalısınız?
x64 seçeneğiniz olmadığında, büyük belgeleri daha küçük parçalara ayırın ve daha düşük bir çözünürlükte işleyin. Performans ve doğrulukta bir değiş-tokuş bekleyin. 32-bit projeler için stabil destek şu anda inceleniyor.
IronOCR çok miktarda bellek gerektiren işlemleri arka planda çalıştırır, bu yüzden bir 32 bitlik (x86) yapı, ~2GB bellek tavanına ulaşır ve büyük veya yoğun belgelerde başarısız olur. 64-bit'i (x64) hedeflemek çözümü sağlar.
32-bit bir işlem, makinenin ne kadar RAM'i olursa olsun yaklaşık 2GB kullanılabilir bellekle sınırlandırılmıştır. Bu limit altında, OCR çalışmaları genellikle şu şekilde yüzeye çıkar:
System.OutOfMemoryException
System.OutOfMemoryException
Text
Aynı tavanın diğer belirtileri arasında, OCR motoru çalıştırılırken kilitlenmeler, görüntü ön işleme sırasında kaynak yetersizliği, çökmeler veya işlenmeyen istisnalar ve sessizce başarısız olan veya süre aşımına uğrayan OCR sonuçları yer alır.
Baskı, IronOCR'un her belge üzerinde gerçekleştirdiği işlemlerden gelir: yüksek çözünürlüklü görüntü oluşturma, geçici rasterleştirme, optik karakter tanıma ve makine öğrenme modeli kullanan derin metin çıkarımı (AdvancedScan yöntemleri ve SearchablePDF çıktısı tarafından kullanılır). Bunlardan her biri belge başına yüzlerce MB gerektirebilir ve çok sayfalı PDF'ler, çok sayfalı TIFF'ler ve 300 + DPI görüntüler bu ihtiyacı daha da artırır.
Lütfen dikkate alın: IronOCR ayrıca OCR, görüntü işleme ve PDF rasterleme için yerel kütüphaneleri çağırır. Bunlar, .NET çöp toplayıcının göremediği yönetilmeyen bellek atarlar, bu da zaten 32 bitlik bir işlemede baskıyı daha da artırır.
Proje AnyCPU olduğunda <Prefer32Bit>false</Prefer32Bit> satırı önemlidir: bu etkinleştirilmişse, uygulama hala 32-bit bir işlem olarak başlatılır ve aynı tavanı devralır.
Uyarı: 32-bit'in tercih edildiği 'AnyCPU'yu kullanmaktan kaçının. Bu sessizce 2GB sınırını, 64-bit bir makinede yeniden tanıtır.
Mimariyi Ne Zaman Şüphelenmeli?
Eğer OCR çalışmaları aniden duraklıyor veya çöküyorsa, aralıklı bellek yetersizlik hataları veya yüksek hacimli belgelerde performans kaybı yaşıyorsanız, önce mimariyi kontrol edin. Eğer x86 çalışıyorsanız, başka bir şey incelemeden önce x64'e geçin.
Üretimde birkaç alışkanlık edinin:
Üretim İçin x64 Hedefleyin: ağır OCR iş yükleri için tek desteklenen yapılandırmadır.
x64 Üzerinde Geliştirin: x64 üzerinde test yapmak gerçek dünya bellek davranışını yansıtır ve sorunları erken tespit eder.
64-bit Docker görüntüleri oluşturun: ana görüntünün linux/amd64 olduğundan emin olun.
Unutmayın ki eş zamanlı OCR çalışmaları hafızayı hızla yükseltir. Küçük belgelerde bile, çok iş parçacıklı veya asenkron işlemler hızla tırmanabilir.
Mimariyi Değiştiremezseniz Ne Yapmalısınız?
x64 seçeneğiniz olmadığında, büyük belgeleri daha küçük parçalara ayırın ve daha düşük bir çözünürlükte işleyin. Performans ve doğrulukta bir değiş-tokuş bekleyin. 32-bit projeler için stabil destek şu anda inceleniyor.
Curtis Chau, Bilgisayar Bilimleri alanında Lisans Derecesine (Carleton Üniversitesi) sahip ve Node.js, TypeScript, JavaScript ve React konularında uzmanlaşmış ön uç geliştirmeyle ilgileniyor. Sezgisel ve estetik açıdan hoş kullanıcı arayüzleri oluşturma tutkunu, Curtis modern çerçevelerle çalışmayı ve iyi yapılandırılmış, görsel olarak çekici kılavuzlar oluşturmayı seviyor.
