Comments
2 comments
-
The AST parser is compiled from an ANTLR 2.0 grammar - one of the idiosyncracies of this code is that it tends to use exceptions for backtracking. We've looked into upgrading this to a version that doesn't throw so many exceptions, but decided at the time that the performance gains were negligible. Of course, we weren't considering performance with a debugger attached.
The only solution I can think of would be to run the Compare Engine in a separate process, so that the debugger is only attached to your main process. -
Hey Sam,
Apologies for the late response. It appears that the forums were changed.
Thank you for your recommendation. Until an update takes place on the AST parser, I'll take your advice for running the compare engine in a separate process.
Add comment
Please sign in to leave a comment.
I'm aware of the null insertion for the optional parameter ScriptDatabaseInformation dbinfo, because this is a database that is stored locally and created using SQL Source Control, it contains a valid xml file. We have been using SQL Source Control and the Comparison SDK for a number of years now.
Our application which uses the Comparison SDK is able to register a database stored on source control in less than a minute. However, registering a local one while debugging in VS takes upward of 30 minutes. SQL Compare through the GUI does not have this issue. This occurs both when the application uses Comparison SDK 11 and 12.