แม้ว่าคำถามนี้จะได้รับคำตอบแล้ว แต่ฉันคิดว่าฉันสามารถพูดได้สองเซ็นต์
การปฏิเสธความรับผิด : ฉันทำงานให้กับ ESRI ที่ทีม GeoDatabase เป็นเวลาหลายปีและรับผิดชอบในการบำรุงรักษาส่วนต่าง ๆ ของรหัส GeoDatabase (การกำหนดเวอร์ชัน, เคอร์เซอร์, EditSessions, ประวัติศาสตร์, คลาสความสัมพันธ์ ฯลฯ )
ฉันคิดว่าแหล่งที่มาที่ใหญ่ที่สุดของปัญหาประสิทธิภาพการทำงานกับรหัส ESRI ไม่เข้าใจความหมายของการใช้วัตถุต่าง ๆ โดยเฉพาะอย่างยิ่งรายละเอียด "เล็กน้อย" ของ abstractions GeoDatabase ต่างๆ! บ่อยครั้งที่การสนทนาเปลี่ยนไปใช้ภาษาที่เป็นตัวการสำคัญของปัญหาด้านประสิทธิภาพ ในบางกรณีก็สามารถ แต่ไม่ใช่ตลอดเวลา มาเริ่มกันที่การสนทนาภาษากันก่อน
1.- ภาษาการเขียนโปรแกรมที่คุณเลือกมีความสำคัญเฉพาะเมื่อคุณกำลังทำสิ่งที่ซับซ้อนในวงแคบ ส่วนใหญ่แล้วนี่ไม่ใช่กรณี
ช้างขนาดใหญ่ในห้องคือที่หลักของทุกรหัส ESRI ที่คุณมี ArcObjects - และArcObjects ถูกเขียนใน C ++ ใช้ COM มีค่าใช้จ่ายในการสื่อสารกับรหัสนี้ สิ่งนี้เป็นจริงสำหรับ C #, VB.NET, python หรืออะไรก็ตามที่คุณใช้
คุณชำระราคาเมื่อเริ่มต้นรหัสนั้น นั่นอาจเป็นค่าใช้จ่ายเล็กน้อยหากคุณทำเพียงครั้งเดียว
จากนั้นคุณจ่ายราคาทุกครั้งที่คุณโต้ตอบกับ ArcObjects
โดยส่วนตัวฉันมักจะเขียนรหัสสำหรับลูกค้าของฉันใน C # เพราะง่ายและเร็วพอ อย่างไรก็ตามทุกครั้งที่ฉันต้องการย้ายข้อมูลไปรอบ ๆ หรือทำการประมวลผลสำหรับข้อมูลจำนวนมากที่ถูกนำไปใช้ในการประมวลผลทางภูมิศาสตร์แล้วฉันเพิ่งเริ่มต้นระบบย่อยการเขียนสคริปต์และส่งผ่านพารามิเตอร์ของฉัน ทำไม?
- มันถูกนำไปใช้แล้ว เหตุใดจึงต้องคิดค้นล้อใหม่
- มันจริงอาจจะเร็วขึ้น "เร็วกว่าเขียนใน C #?" ใช่ ถ้าฉันใช้พูดโหลดข้อมูลด้วยตนเองก็หมายความว่าฉันจ่ายราคาของ. NET การสลับบริบทในวงแน่น ทุก GetValue, แทรก, ShapeCopy มีค่าใช้จ่าย ถ้าฉันโทรหนึ่งครั้งใน GP กระบวนการโหลดข้อมูลทั้งหมดนั้นจะเกิดขึ้นในการนำ GP ไปใช้จริงในสภาพแวดล้อม COM ฉันไม่จ่ายราคาสำหรับการสลับบริบทเพราะไม่มี - และด้วยเหตุนี้มันจึงเร็วกว่า
อ๋อใช่แล้วถ้าจะใช้ฟังก์ชั่นการประมวลผลทางภูมิศาสตร์ ที่จริงแล้วคุณต้องระวัง
2. GP เป็นกล่องดำที่คัดลอกข้อมูล (อาจไม่จำเป็น)
มันเป็นดาบสองคม มันเป็นกล่องดำที่ใช้เวทมนตร์บางอย่างภายในและแยกผลลัพธ์ออกมา แต่ผลลัพธ์เหล่านั้นซ้ำกันบ่อยมาก 100,000 แถวสามารถแปลงเป็น 1,000,000 แถวบนดิสก์ได้อย่างง่ายดายหลังจากคุณเรียกใช้ข้อมูลของคุณผ่าน 9 ฟังก์ชันที่แตกต่างกัน การใช้ฟังก์ชั่น GP เพียงอย่างเดียวก็เหมือนกับการสร้างโมเดล GP เชิงเส้นและ ...
3. การกำหนดฟังก์ชั่น GP มากเกินไปสำหรับชุดข้อมูลขนาดใหญ่นั้นไม่มีประสิทธิภาพสูง GP Model คือ (อาจ) เทียบเท่ากับการดำเนินการสืบค้นด้วยวิธีที่โง่จริงๆ
ตอนนี้อย่าเข้าใจฉันผิด ฉันชอบโมเดล GP - มันช่วยฉันจากการเขียนรหัสอยู่ตลอดเวลา แต่ฉันก็ทราบด้วยว่ามันไม่ใช่วิธีที่มีประสิทธิภาพที่สุดในการประมวลผลชุดข้อมูลขนาดใหญ่
คุณเคยได้ยินQuery Plannerบ้างไหม? มันเป็นงานที่จะดูคำสั่ง SQL ที่คุณต้องการที่จะดำเนินการสร้างแผนการดำเนินการในรูปแบบของกราฟกำกับที่มีลักษณะเหมือน heck มากเช่นแบบจำลอง GP , ดูสถิติที่เก็บไว้ในฐานข้อมูลและเลือกมากที่สุด การสั่งซื้อที่เหมาะสมที่จะดำเนินการให้ GP เพียงรันพวกเขาในการที่คุณนำสิ่งเพราะมันไม่ได้มีสถิติที่จะทำอะไรอย่างชาญฉลาดมากขึ้น - คุณจะวางแผนแบบสอบถาม และคาดเดาอะไร ลำดับที่คุณดำเนินการสิ่งต่าง ๆ นั้นขึ้นอยู่กับชุดข้อมูลของคุณ ลำดับที่คุณดำเนินการสิ่งต่าง ๆ สามารถสร้างความแตกต่างระหว่างวันและวินาทีและขึ้นอยู่กับคุณในการตัดสินใจ
คุณพูดว่า "เยี่ยมมาก" ฉันจะไม่เขียนบทด้วยตัวเองและระมัดระวังเกี่ยวกับวิธีเขียนสิ่งต่างๆ แต่คุณเข้าใจ abstractions GeoDatabase หรือไม่
4. ไม่เข้าใจ abstractions GeoDatabase สามารถกัดคุณได้อย่างง่ายดาย
แทนที่จะชี้ให้เห็นทุกสิ่งที่เป็นไปได้ที่จะทำให้คุณมีปัญหาให้ฉันแค่ชี้ให้เห็นข้อผิดพลาดทั่วไปบางอย่างที่ฉันเห็นตลอดเวลาและคำแนะนำบางอย่าง
- เข้าใจความแตกต่างระหว่างถูก / ผิดสำหรับเคอร์เซอร์รีไซเคิ่ล การตั้งค่าสถานะเล็กน้อยเล็ก ๆ นี้เป็นจริงสามารถทำให้คำสั่งรันไทม์ของขนาดเร็วขึ้น
- วางตารางของคุณในLoadOnlyModeสำหรับโหลดข้อมูล ทำไมต้องอัพเดตดัชนีในทุกส่วนแทรก?
- เข้าใจว่าถึงแม้ว่า IWorkspaceEdit :: StartEditing จะมีลักษณะเหมือนกันในพื้นที่ทำงานทั้งหมด แต่เป็นสัตว์ร้ายที่แตกต่างกันมากในทุกแหล่งข้อมูล ใน Enterprise GDB คุณอาจมีเวอร์ชันหรือรองรับธุรกรรม ในรูปร่างไฟล์นั้นจะต้องมีการใช้งานในวิธีที่แตกต่างกันมาก คุณจะใช้ Undo / Redo อย่างไร คุณจำเป็นต้องเปิดใช้งานหรือไม่ (ใช่มันสามารถสร้างความแตกต่างในการใช้หน่วยความจำได้)
- ความแตกต่างระหว่างการดำเนินการแบทช์หรือการดำเนินงานแถวเดียว กรณีตรงประเด็นGetRow vs GetRows - นี่คือความแตกต่างระหว่างการทำแบบสอบถามเพื่อรับหนึ่งแถวหรือทำหนึ่งแบบสอบถามเพื่อดึงข้อมูลหลายแถว การวนลูปอย่างแน่นหนาพร้อมการเรียกใช้ GetRow หมายถึงประสิทธิภาพที่น่ากลัวและเป็นสาเหตุของปัญหาด้านประสิทธิภาพอันดับที่ 1
- ใช้UpdateSearchedRows
- เข้าใจความแตกต่างระหว่างCreateRowและCreateRowBuffer ความแตกต่างอย่างมากในการแทรกไทม์
- ทำความเข้าใจกับIRow :: Storeและ IFeature :: Store ทำให้เกิดการดำเนินการpolymorphic ที่หนักหน่วงเป็นพิเศษ นี่อาจเป็นเหตุผล # 2 ผู้ร้ายประสิทธิภาพช้า มันไม่เพียงบันทึกแถวนี่เป็นวิธีที่ทำให้แน่ใจว่าเครือข่ายทางเรขาคณิตของคุณเป็นปกติที่ตัวแก้ไข ArcMap จะได้รับแจ้งว่าแถวมีการเปลี่ยนแปลงซึ่งจะแจ้งให้ทราบถึงคลาสความสัมพันธ์ทั้งหมดที่มีส่วนเกี่ยวข้องกับแถวนี้ แน่ใจว่า cardinality นั้นถูกต้อง ฯลฯ คุณไม่ควรแทรกแถวใหม่ด้วยสิ่งนี้คุณควรใช้InsertCursor !
- คุณต้องการ (จำเป็น) ทำเม็ดมีดเหล่านั้นใน EditSession หรือไม่? มันสร้างความแตกต่างอย่างมากถ้าคุณทำหรือไม่ การดำเนินการบางอย่างจำเป็นต้องใช้ (และทำให้สิ่งต่าง ๆ ช้าลง) แต่เมื่อคุณไม่ต้องการให้ข้ามคุณสมบัติการเลิกทำ / ทำซ้ำ
- เคอร์เซอร์เป็นทรัพยากรที่มีราคาแพง เมื่อคุณมีหมายเลขอ้างอิงถึงหนึ่งคุณจะรับประกันได้ว่าคุณจะมีความสอดคล้องและความโดดเดี่ยวและมีค่าใช้จ่าย
- แคชทรัพยากรอื่น ๆ เช่นการเชื่อมต่อฐานข้อมูล (ไม่ต้องสร้างและทำลายการอ้างอิงเวิร์กสเปซของคุณ) และตัวจัดการตาราง (ทุกครั้งที่คุณเปิดหรือปิดหนึ่งตาราง - เมตาดาต้าตารางจำนวนมากต้องอ่าน)
- การวาง FeatureClasses ภายในหรือภายนอก FeatureDataset สร้างความแตกต่างอย่างมากในประสิทธิภาพ มันไม่ได้หมายถึงเป็นคุณลักษณะขององค์กร!
5. และสุดท้ายและไม่น้อย ...
ทำความเข้าใจกับความแตกต่างระหว่างI / O bound และการทำงานของ CPU bound
ฉันคิดอย่างจริงใจเกี่ยวกับการเพิ่มมากขึ้นในแต่ละรายการเหล่านั้นและอาจทำรายการบล็อกที่ครอบคลุมทุกหัวข้อเหล่านั้น แต่รายการในมือของปฏิทินของฉันเพิ่งตบหน้าและเริ่มตะโกนใส่ฉัน
สองเซ็นต์ของฉัน