For anyone who's used xmlArchitect for good sized files (50kb plus) may have noticed some slowdowns in general speed. Making changes in the Tree will automatically update the text, and visa-versa, all in real time. During development, files rarely got too large, so speed was never a large concern.
Recently, one of our users tried them against the OAG Schemas (www.openapplications.org), an open set of standard Schemas used for business, and these schemas are quite large and utilize a lot of the features of XML Schemas. It was a humbling experience to put xmlArchitect to the test and see what it would do. After some minor tweaks (resulting in release 0.1.0.19), the files would display properly, however due to the size and reuse of comlexTypes, the amount of time it took to generate the XML Tree pretty much rendered xmlArchitect useless. This has brought us back to the question of speed optimizations.
Looking at the code, there's a lot that could be done to optimize it, and it looks like that will be the next big step in xmlArchitect; It's refactor time, baby!
At any rate, this is notice that a lot of changes will take place in the code before the next big release of xmlArchitect. These changes are being slightly postponed for xmlAssimilator (see threads in the "general" group), a project that's near completion and we want to finish that before regearing ourselves to a big change in xmlArchitect.
-BKN
Recently, one of our users tried them against the OAG Schemas (www.openapplications.org), an open set of standard Schemas used for business, and these schemas are quite large and utilize a lot of the features of XML Schemas. It was a humbling experience to put xmlArchitect to the test and see what it would do. After some minor tweaks (resulting in release 0.1.0.19), the files would display properly, however due to the size and reuse of comlexTypes, the amount of time it took to generate the XML Tree pretty much rendered xmlArchitect useless. This has brought us back to the question of speed optimizations.
Looking at the code, there's a lot that could be done to optimize it, and it looks like that will be the next big step in xmlArchitect; It's refactor time, baby!
At any rate, this is notice that a lot of changes will take place in the code before the next big release of xmlArchitect. These changes are being slightly postponed for xmlAssimilator (see threads in the "general" group), a project that's near completion and we want to finish that before regearing ourselves to a big change in xmlArchitect.
-BKN
