WOW!
I’m not sure what else to say!
Well, let me start by backing up a bit…
I finally decided this afternoon I was going to install AutoCAD Map 3D 2011. Even though this was just released, I have been debating this for some time now, and wasn’t sure how I was going to proceed. You see, some of the other techs within IMAGINiT have been making the jump to Windows 7 AND 64bit, and I wasn’t sure if I was ready for this. Don’t get me wrong, I love being on the ‘bleeding edge’ of technology and would like nothing more than to move to an a new OS and one that will support more memory. But unfortunately, there are just too many unknowns, and known issues, like lack of ODBC support on 64bit, for me to be comfortable in making this move. Long story, not-so short, I decided I was not ready to take this leap.
So, no need to wait… I might as well get that latest release of AutoCAD Map 3D installed on my production machine ASAP.
While it’s no secret that there are not many ‘new features’ to boast about this time around, one of the enhancements being talked up is the improvements in caching and updates to the FDO Providers.
We are currently working on migrating a clients VBA application, and one of the new features of this application will be accessing cadastral base information stored in a SQL Server Spatial database. The performance in AutoCAD Map 3D 2010 wasn’t what I would have considered as ‘production ready’, so I was specifically interested in seeing some improvements to the SQL Server Spatial Provider.
Well, now with 2011 installed, the first thing I wanted to check out was connecting to, and querying, some data from SQL Server. There are a couple of things I noticed soon after executing some test queries; first off, the layers appear IMMEDIATELY in the Display Manager, secondly, the queries were substantially quicker, and thirdly, the caching seems to be happening transparently and a person could continue to work as the data is being cached and displayed on the screen.
The dataset consists of:
- Cadastral base data (NAD 83 CSRS, Zone 13) for the province of Saskatchewan
- Data stored in a Foreign Schema in SQL Server
My test scenario included:
- Querying a single Township
- Querying an additional 13 themes (layers) of data within this Township
I wouldn’t consider this an official benchmark test of any sort, but it is a sufficient enough test to prove whether or not there are any substantial differences in the overall query/caching time. In this first test, of the 13 feature layers being queried, only 3 layers actually contain features within this township, and there are only a total of 153 features. So this is actually a very small dataset, but yet it took some time to query in…
Test Results:
In AutoCAD Map 3D 2010 it took over 2.5 minutes until the layers were visible in the Display Manager, and just about another 1.5 minutes until all of the features were visible, for a total query time of just under 4 minutes.
The results in AutoCAD Map 3D 2011 were much improved. As stated earlier, the layers were immediately visible in the Display Manager, and the entire query was completed in just over 1 minute.
That’s fairly convincing to show that there is a performance improvement, but I wanted to run this on a little larger dataset as well. The second test scenario was the same as the first except within a different township that included more data. This particular township contained over 8800 features coming from 8 feature layers (5 empty).
On this test, in 2010 the total running time was about 5:45, and in 2011, the total running time was about 1:45.
While I believe there is still definitely plenty of room for improvement, it is easy to see that there is a major performance improvement with respect to the SQL Server FDO Provider in AutoCAD Map 3D 2011.
Now… Having said all of that, I’m sure there are some people questioning the fact that it took ‘just over a minute’ to query in 153 features. That is true, BUT, it was querying 13 different themes to get this data, and I feel it is important not to get ‘hung-up’ on the amount of time particular query takes to execute. We need to ensure that we are comparing apples-to-apples, and oranges-to-oranges… IOW, we cannot (or should not) look at this and say,
“Gee, it only takes me a couple seconds to open a drawing with that same data in it, why would I want to have this information stored in a database and have it take a minute to execute the query?”
Why? Because we need to look past the immediate gratification of a ‘drawing opening fast’, and realize that there are many other benefits to an organization as a result of having the data located in a central repository. Having the data accessible to the entire organization opens up unlimited opportunities for data consumption from a wide variety of applications, clients, and people. In most situations these benefits would far outweigh the inconvenience of a executing a query that takes an extra minute to run.
Stepping off my soap-box now…
Until next time,
Take care
Warren M