Changes between Version 1 and Version 2 of MapGuideRfc116
- Timestamp:
- Jun 16, 2011, 4:10:20 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc116
v1 v2 33 33 The proposed submission would not change any existing functionality or method signatures. The proposal introduces five new members to the currently existing MgCoordinateSystemTransform interface. This RFC includes an outline of the recommended usage of the API which will provide the optimum performance of the API. 34 34 35 Using the metric of the number of conversions per second from UTM27-13 to CO83-C in a pure measurement environment (i.e. no coordinate retrieval or delivery code), the underlying CS-MAP library is capable of producing approximately 1 million conversions per second. Changes in the MapGuide API, therefore, cannot get us beyond this limit. Thus, in this RFC, we will write of performance in terms of the percentage of this theoretical maximum which the API can/will deliver. The current implementation of the API delivers performance of approximately 80% of this maximum. Research and test implementations indicate that it is not unreasonable to expect an improvement to 91% of the theoretical maximum .35 Using the metric of the number of conversions per second from UTM27-13 to CO83-C in a pure measurement environment (i.e. no coordinate retrieval or delivery code), the underlying CS-MAP library is capable of producing approximately 1 million conversions per second. Changes in the MapGuide API, therefore, cannot get us beyond this limit. Thus, in this RFC, we will write of performance in terms of the percentage of this theoretical maximum which the API can/will deliver. The current implementation of the API delivers performance of approximately 80% of this maximum. Research and test implementations indicate that it is not unreasonable to expect an improvement to 91% of the theoretical maximum when using the most efficient Transform functions. 36 36 37 37 Achieving this level of improvement is deemed possible by four distinct tasks involving the API. 38 Removing the Requirement for a Crtitical Section 38 39 == Removing the Requirement for a Crtitical Section === 40 39 41 Currently, there are specific transformations within the CS-MAP library which are not reentrant. Therefore, to insure proper operation in a multi-threaded environment, a critical section is used for all datum shift calculations. It is the intent of this RFC to remove this requirement. Assuming the acceptance and implementation of OsGeo MetaCRS RFC #5, CS-MAP will enable the API to query CS-MAP and determine if a critical section is necessary for a specific transformation. The API will be modified to use this information and invoke the critical section only as necessary. 40 42 … … 52 54 === Refactor the MgCoordinateSystemTransformation::Transform Functions === 53 55 It is proposed that the existing implementation of all of the Transform overloads in the existing MgCoordinateSystemTransformation object be refactored for performance purposes. It is contemplated that by : a) reducing the number of changes of the form of a coordinate takes, b) removing some internal function calls by replicating code to a small degree, and c) reducing the overhead implied by several layers of try {} catch blocks; that significant performance enhancements can be achieved. This work will introduce some minor changes in behavior which are considered to be improvements in consistency and usefulness of the API and only affects behavior in extraordinary cases. These changes are detailed below. 56 54 57 === Conversion Status Accumulation === 58 55 59 CS_MAP issues warnings for coordinates outside the useful range of the coordinate systems (and the datums referenced by them) used to construct the MgCoordinateSystemTransformation object. These are warnings and do not mean that the returned coordinates are invalid. It should not be considered abnormal for a small sub-set of the coordinates in a large conversion to be outside the useful range of a Transformation object. In the event that a large number of coordinates in a conversion are found to be outside the useful range, it is valid to question the validity of the conversion. Such a case is a strong indication that the user may not have selected the proper coordinate system for a specific conversion. 56 60 However, currently the default behavior of the API is to throw an exception in whenever such a warning is received from the CS-MAP library. Applications then either consider the conversion to be a failure, or essentially ignore the exception. In the former case, this is not always the correct conclusion. It is not uncommon for a geometry or map of a large region to occasionally stray outside the useful range of a coordinate system. The results CS-MAP returns, even in the case of a warning are totally appropriate given the coordinate values it has been asked to convert. In the latter case, in the event of the user choosing an incorrect coordinate system for the data in use, the application can appear to hang as measurements indicate that disposing of an exception in this case can consume 15 milliseconds of clock time for each point. … … 76 80 The above new functions can be used at anytime during a large conversion to determine the accumulated status of the conversion. Thus, a very large conversion can be terminated prematurely if it appears that after a significant number of conversions have been performed the ultimate failure appears to be likely. 77 81 The addition of this improved status monitoring capability is expected to make the disabling of exception processing while performing large conversions an acceptable practice and is, therefore, considered to be and important contribution to providing higher performance levels. 78 Provide Additional Batch Coordinate Conversion Capability 82 83 === Provide Addiional Batch Coordinate Conversion Capability === 84 79 85 A batch coordinate conversion capability currently exists in the MgCoordinateSystemTransformation object. The performance of this capability is expected to increase due to the refactoring of the Transform code proposed immediately above. However, this function requires that, for example, 3D coordinates are provided in three distinct arrays; specifically the easting/X/Longitude coordinates in one distinct array of doubles, the northing/Y/Latitude coordinates in a separate distinct array of doubles, and a third separate and distinct array of double for the elevation/Z/height coordinate. There are few, if any, applications which maintain or utilize coordinate data in this form. Thus, to take advantage of the batch conversion facility currently in place, the tradition form of coordinate data (i.e. double [][3]) has to be reformatted into the distinct array form prior to conversion, and then reformatted back to the traditional form after conversion. Thus, what performance improvement is provided by the batch conversion facility is used up, and then some, by the reformatting process. 80 86 It is, therefore proposed, that two new functions be added to the MgCoordinateSystemTransformation object be added which will have signatures suggested by the following: … … 85 91 == Implications == 86 92 87 === Critical Section Still Required ===93 === Critical Section Still Required === 88 94 89 95 It would be nice to assume that all current CS-MAP coordinate conversion algorithms can be made reentrant without a serious affect on resources and/or performance, and that all future additions to the CS-MAP library can be implemented in a reentrant manner. The ability to have non-reentrant conversion/transformation methods in the CS-MAP library is reserved. Thus, we retain the CriticalSection to keep multiple threads from using a non-reentrant conversion or transformation at the same time. However, given the implementation of CS-MAP RFC #5, we will only need to actually use it when truly necessary. 90 96 91 === Behavior Modifications ===97 === Behavior Modifications === 92 98 93 99 A substantial portion of the increased performance to be achieved will be derived from a refactoring of the coordinate system conversion code. Over the years, this code has become somewhat inefficient using several nested function calls with non-trivial signatures. In refactoring this code, the following changes in behavior (more like corrections) will be made: … … 109 115 Successful operation of 16 randomly started threads for a period of 20 seconds (an average of 20 executions of the test sequence by 16 different threads, producing 320 executions of each test sequence) will be considered success. Clearly, the test would be more conclusive if run on a machine with more than two cores. 110 116 111 == Funding/Resources ==117 == !Funding/Resources == 112 118 113 119 Funding and developer resources to be provided by Autodesk.
