Bu sorunun cevabı çoktan cevaplanmış olmasına rağmen, iki sentimi verdiğimde çalabileceğimi düşündüm.
YASAL UYARI : Birkaç yıl boyunca GeoDatabase ekibinde ESRI için çalıştım ve GeoDatabase kodunun çeşitli bölümlerini (Sorumluluk, İmleçler, Düzenleme, Tarih, İlişki Sınıfları, vb.) Korumaktan sorumluydum.
ESRI kodundaki en büyük performans sorunlarının kaynağının, farklı nesnelerin, özellikle de çeşitli GeoDatabase soyutlamalarının "küçük" ayrıntılarının kullanılmasının etkilerini anlamadığını düşünüyorum! Çok sık olarak, konuşma, performans sorunlarının suçlusu olarak kullanılan dile geçer. Bazı durumlarda olabilir. Fakat her zaman değil. Dil tartışması ile başlayalım ve geri dönüş yolumuza gidelim.
1.- Seçtiğiniz programlama dili sadece karmaşık bir işlemi yaparken sıkı bir döngüde önemlidir. Çoğu zaman, durum bu değil.
Odadaki büyük fil, tüm ESRI kodlarının merkezinde, ArcObjects'e sahip olmanız - ve ArcObjects, COM kullanarak C ++ dilinde yazılmıştır . Bu kodla iletişim kurmanın bir bedeli vardır. Bu, C #, VB.NET, python veya kullandığınız diğer şeyler için geçerlidir.
Bu kodun başlangıcında bir bedel ödersiniz. Sadece bir kez yaparsanız bu ihmal edilebilir bir maliyet olabilir.
Ardından, ArcObjects ile etkileşime girdiğiniz her bir sonraki zaman için bir ücret ödersiniz.
Şahsen, müşterilerim için C # kodunu yazma eğilimindeyim, çünkü yeterince kolay ve hızlı. Ancak, ne zaman Geoprocessing uygulamasında halihazırda uygulanmış büyük miktarda veri için veri taşımak veya bazı işlemler yapmak istediğimde sadece komut dosyası alt sistemini başlatıyorum ve parametrelerimi iletiyorum. Neden?
- Çoktan uygulandı. Peki neden tekerleği yeniden icat ettin?
- Aslında daha hızlı olabilir . "C # ile yazmaktan daha hızlı?" Evet! Veri yüklemeyi manuel olarak uygularsam, bunun anlamı, .NET bağlamında anahtarlama yapmak için sıkı bir döngü ücreti ödüyorum. Her GetValue, Insert, ShapeCopy'nin bir maliyeti vardır. Bir aramayı GP’de yaparsam, veri yükleme işleminin tamamı GP ortamında C ++’da COM ortamında gerçekleşir. Bağlam geçişi için fiyat ödemiyorum çünkü hiçbiri yok - ve dolayısıyla daha hızlı.
Ah evet, öyleyse çözüm çok sayıda coğrafi işlem işlevinin kullanılması durumunda. Aslında dikkatli olmalısın.
2. GP, verileri (potansiyel olarak gereksiz yere) etrafa kopyalayan bir kara kutudur.
İki ucu keskin bir kılıçtır. İçinde bir miktar sihir yapan ve sonuçları tüküren bir kara kutu. Fakat bu sonuçlar sıklıkla çoğaltılıyor. Verilerinizi 9 farklı işlevde çalıştırdıktan sonra, 100.000 satır kolayca disk üzerinde 1.000.000 satıra dönüştürülebilir. Yalnızca GP işlevlerini kullanmak, doğrusal bir GP modeli oluşturmak gibidir ve peki ...
3. Büyük veri kümeleri için çok fazla GP işlevi zincirleme son derece yetersizdir. Bir GP Modeli (potansiyel olarak) gerçekten çok aptalca bir şekilde bir sorgu yürütmeye eşdeğerdir
Şimdi beni yanlış anlama. GP Modellerini çok seviyorum - her zaman kod yazmaktan kurtarıyor. Ancak bunun büyük veri setlerini işlemenin en etkili yolu olmadığını da biliyorum.
Bir Sorgu Planlayıcısı duydunuz mu? Yapılması gereken SQL ifadesine bakmak, GP Modeline çok benzeyen, yönlendirilmiş bir grafik biçiminde bir yürütme planı oluşturmak, db'de depolanan istatistiklere bakmak ve en çok seçmek bunları yürütmek için en uygun sipariş . GP sadece bunları bir şeyler koyma sırasına göre yürütür, çünkü daha akıllıca bir şey yapacak istatistiklere sahip değildir - siz sorgu planlamacısınız . Ve tahmin et ne oldu? Bir şeyleri yürütme sırası veri kümenize çok bağlıdır. Bir şeyleri uyguladığınız sıra, günler ve saniyeler arasında fark yaratabilir ve bu size karar vermek size kalmış.
"Harika" diyorsun, kendim bir şeyler yazmayacağım ve bir şeyler nasıl yazdığım konusunda dikkatli olacağım. Ama GeoDatabase soyutlamalarını anlıyor musunuz?
4. GeoDatabase soyutlamaları anlamıyorum kolayca sizi ısırır
Size sorun çıkarabilecek her şeyi işaret etmek yerine, her zaman gördüğüm birkaç ortak hatayı ve bazı önerileri göstereyim.
- Geri Dönüşüm imleçleri için Doğru / Yanlış arasındaki farkı anlama . True olarak ayarlanan küçük minik bayrak, çalışma zamanı siparişlerini daha hızlı hale getirebilir.
- Veri yüklemeleri için tablonuzu LoadOnlyMode'a yerleştirin . Neden her yazıdaki dizini güncelle?
- IWorkspaceEdit :: StartEditing'in tüm çalışma alanlarında aynı görünse de, her veri kaynağında çok farklı canavarlar olduğunu anlayın. Enterprise GDB'de işlemlerde sürüm veya destek alabilirsiniz. Şekil dosyalarında, çok farklı bir şekilde uygulanması gerekecektir. Geri Al / Yinele'yi nasıl uygularsınız? Bunu etkinleştirmeniz bile gerekiyor mu (evet, bellek kullanımında bir fark yaratabilir).
- Toplu işlemler veya tek satır işlemleri arasındaki fark. Örnek olayda GetRow - GetRows - bu bir satır almak için bir sorgu yapmak veya birden fazla satır almak için bir sorgu yapmak arasındaki farktır. GetRow çağrısı ile yapılan sıkı bir döngü, korkunç performans anlamına gelir ve performans sorunlarının 1. sorumlusu
- UpdateSearchedRows kullanın
- CreateRow ve CreateRowBuffer arasındaki farkı anlayın . İnsert çalışma zamanındaki büyük fark.
- IRow :: Store ve IFeature :: Store'un süper ağır polimorfik işlemleri tetiklediğini anlayın . Bu muhtemelen gerçekten yavaş performansın 2. numaralı suçluluğudur. Yalnızca satırı kaydetmiyor, geometrik ağınızın iyi durumda olduğundan emin olmak için kullanılan yöntemdir, ArcMap Editor'ün bir satırın değiştiğini, bu satırla ilgisi olan tüm ilişki sınıflarını bildiren bir satırın değiştiğini bildirir. kardinalliğin geçerli olduğundan emin olun, vb. Bununla yeni satırlar eklememelisiniz, bir InsertCursor kullanmalısınız !
- Bir EditSession'da bu ekleri yapmak ister misiniz (gerekir)? İsterseniz ister olmasanız çok büyük bir fark yaratır Bazı işlemler gerektirir (ve işleri daha da yavaşlatır), ancak ihtiyacınız olmadığında geri alma / yineleme özelliklerini atlayın.
- İmleçler pahalı kaynaklardır. Bire bir kulpunuz olduğunda, Tutarlılık ve İzolasyon yapacağınız ve bunun bir maliyeti olduğu garantilidir .
- Veritabanı bağlantıları gibi diğer kaynakları önbelleğe alın (Çalışma alanı referansınızı oluşturup yok etmeyin) ve Tablo tanıtıcıları (her birini açtığınızda veya kapattığınızda - birkaç meta veri tablosunun okunması gerekir).
- FeatureClass'ları bir FeatureDataset'in içine veya dışına koymak, performansta büyük fark yaratır. O edilir değil bir organizasyon özelliği olarak geliyordu!
5.Ve son ve en az değil ...
G / Ç sınırı ve CPU'ya bağlı işlemler arasındaki farkı anlayın
Dürüst olmak gerekirse, bu öğelerin her birinde daha fazla genişletmeyi ve belki de bu konuların her birini kapsayan bir dizi blog girişi yapmayı düşündüm, ancak takvimimin biriktirme listesi beni yüzüme tokatladı ve bana bağırmaya başladı.
Benim iki Sentim.