As seen in first part of this performance test, ApexSQL Diff 2012 starts off much faster than its predecessor and here as well, this trend continues. See below how ApexSQL Diff 2012 surpasses the 2011 version as one of the best SQL database compare tools money can buy.
General tests
- Results display
Populate results test in the Main grid is related to GUI performance and it was included in the performance section as it is an essential part of the comparison process, since the populate results process happens in the main grid after the comparison process is completed
For the purpose of this test, a database with 100,000 objects was used against an empty database, which resulted in 100,000 different populated results in the main grid. Time was measured from the moment the comparison process had completed until the main grid was populated with results and all objects were displayed
- Select all/deselect all comparison results
In the latest version of ApexSQL Diff, selecting/deselecting results in the main grid was already well optimized, so most of the improvements in this case came down to additional application code polishing. The test settings were the same as for the Results display test. Time was measured from clicking the “Check all” button until all the rows were checked. The same was done with “Uncheck all”, but in this case until all the rows were unchecked. “Check all” and “Uncheck all” scores were summed up
- Dependencies processing
Some critical bottlenecks were spotted in ApexSQL Diff 2011, which resulted in bad dependencies analysis and synchronization tree generation performances. Therefore, a new approach was established and a new logic of dependencies handling was implemented in ApexSQL Diff 2012 For the purpose of this test, a database with 100,000 objects was used against an empty database, which resulted in a dependencies analysis for all objects
- Object filtering
Using the Object filter in the main application window was another critical bottleneck in ApexSQL Diff 2011. Changes made in the object filter directly influenced the main grid and the populated results there. This test was performed by measuring the time needed for the results to populate in the main grid after clicking “Check all items” in the Object filter panel, up until all the results were populated in the main grid. The same was performed for “Uncheck all items”, but instead measuring the time needed for the main grid to become empty
Live databases, backup to live database, script folder to live database, and source control to live database tests were performed by the same principles
The Complete comparison involves the complete comparison process. It stars when the “Compare” button is clicked in the Project Settings form, up until all populated results are shown in the main grid. The 100,000 object database was used and compared against itself, which resulted in 200,000 objects compared
The Complete synchronization test involves the complete synchronization process. It stars when the “Synchronize” button is clicked in the Main application window, up until the application asks for the generated file to be stored locally. The 100,000 object database was used and synchronized with an empty database, which resulted in 100,000 synchronized objects
The Complete process test involves both previously described tests. User experience often means performing the complete set of actions needed for database synchronization, not just comparison or synchronization. For the purpose of this test, the Complete comparison and the Complete synchronization test times were summed up
- Live databases
- Backup to live database
- Script folder to live database
- Source control to live database
As it can be seen from the results above, optimization in ApexSQL Diff 2012 has resulted in much better performance compared to already very good result which ApexSQL Diff 2011 has shown before
April 12, 2013
