- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I'm working on an aspect of my program that executes a number of geometry comparisons that run fairly slowly. I'm looking at ways to shorten response times and one of the options that shows a great deal of promise is allowing parallel iterations via .NET's Parallel.ForEach().
Now clearly, you're playing with fire if you attempt to get data from a document or modify a document during a parallel iteration. That would have the same dire consequences as trying to mutli thread without proper use of ExternalEvents, etc. What I'm interested in instead is the concept of extracting data in bulk and then performing demanding parallel iterations on a list of objects with no requests for new data and no changes to the Document during iteration.
For example, extract all Element location curves or geometry solids from the Document and store them in a list. Then, use parallel iteration over that list of curves or solids in order to accelerate demanding computation. Clearly, you would want to painstakingly avoid handling any kind of data that contains an explicit reference to the Document, such as Element, ElementId, etc.
In testing, these processes appear very sound, but I want to do my due diligence to make sure this approach squares with the intended use and limitations of the API. Jeremy Tammik answered a Stackoverflow post on a related topic in 2017 (linked here for your reference) .
His response read in part "My recommendation would be to reduce the Revit API interaction and processing to an absolute minimimum, collect all the data required for processing, terminate the Revit API interaction after collecting the data, and then run the pure calculations with no further Revit API interaction in a separate thread or several threads at a later point after leaving the Revit API context.".
So here is my big-picture question: Do geometry objects of type XZY, Line, Plane, Curve, Solid, and similar contain data that inherently references the originating document in a way that creates a crashing or corruption risk during parallel iteration? Or does the approach I'm describing here accurately reflect Jeremy's concept of separating API calls from the mathematical operations?
Solved! Go to Solution.