Memory Hog and gosh darn slow!

• 
  Be careful here. SQL Digger is a GREP-like tool, a text-string searcher. I can easily do what SQL Digger does within one db with a single query:
  

  select distinct
      o.type, o.name
  from
      syscomments c
  inner join
      sysobjects o on c.id = o.id
  where
      c.text like '%cms_getVendorInvoiceList %'
  order by
      o.type, o.name
  

  
  But, if I test for a slightly difference string, I get different results in SQL Digger. Also, it does not show dependencies in a navigable way. I'm not talking about the diagram, but rather the textual viewers.
  
  RGDT is, I think, different. There's probably an SQL parser under the sheets that does some better dependency walking.
  
  As for performance, I have had issues with diagrams that I run over entire large DBs, but as has been said elsewhere, the tool is not intended for such a scenario. I made the same mistake you did of pulling in all objects to isolate those I needed; instead I should have pulled in one and then pulled in related objects as needed.
  
  OTOH, hopefully they can enhance and squeeze out more speed with version revisions.
  
  
  
  - alphadog

  alphadog April 07, 2006 08:53

  - 0 +
• 
  Dear PDinCA,
  
  Thanks for your feedback, and for giving such detailed object counts.
  
  If I understand correctly, your database has ~1643 objects, all of which were on the diagram. If you use SQL Compare, can I ask what the memory usage typically is in that application for the same database?
  
  Some of the performance problems you've had will be gone for the final release. The beta has known issues working with a large number of selected objects. This has already been fixed for the final release.
  
  Performance wise, the application is intended to perform well with up to 500 objects on the diagram at one time. It has no hard limit, but isn't optimised for thousands of objects on the diagram. If your system can take it, then no problem, but some systems won't be able to. As alphadog mentions, for impact analysis the best approach is to start with a small number of objects and add to the diagram as required, rather than starting with the entire database on the diagram and then remove objects which aren't required.
  
  Sadly we have limited time available to work on SQL Dependency Tracker, and as such some features didn't make the cut. Printing was one of those. The primary output envisaged from SQL Dependency Tracker is the diagram, though we do support XML reporting. The diagram is anticipated to be used eg. word processors or presentation applications for illustrations, and so printing wasn't high on our feature list, as those applications already provide it. But with enough demand, a future version of SQL Dependency Tracker may support such features. Also our users are already finding rather cunning solutions of their own (such as pasting into Excel, which seems good at printing large metafiles).
  
  I'm afraid there won't be a CTP version of SQL Dependency Tracker. The next version we release will be the 2.0 final release.
  
  Thanks and all the best,
  Dan
  

  ---

  Dan J Archer
  SQL Dependency Tracker Project Lead

  Dan J Archer April 11, 2006 12:44

  - 0 +
• 
  It's about 70 megs:
  
  Process file name: RedGate.SQLCompare.UI.exe
  Memory usage: 72,360 KB
  File path: C:\Program Files\Red Gate\SQL Bundle 5\RedGate.SQLCompare.UI.exe
  Process ID: 4744
  Thread count: 11
  Priority class: Normal
  Parent process ID: 3832
  Page faults: 247,214
  Peak working set size: 78,464 KB
  Page file usage: 58,356 KB
  Peak page file usage: 64,544 KB
  
  
  I used Word to print the diagram in landscape orientation. The captured image wasn't anywhere near as clear as the monitor image, sadly. The print was just about usable; however, if I had any more than the 14 objects visible, I'd have had to go to Excel. Thanks for dropping that tidbit in your reply - I've never used Excel for printing large images...
  
  Based on the feedback to-date, what's the projected Final Release Date? (I had a quick scoot around your site, but missed this...)

  PDinCA April 11, 2006 12:54

  - 0 +
• 
  Hmm, that does make SQL Dependency Tracker look like a bit of a memory hog doesn't it! I'll ask someone to investigate this. No promises as that size of diagram is beyond the intended scope of this release, but that does seem just a tad OTT...
  
  Re Excel, yes that one surprised the heck out of me too. Credit to sonrisante for finding that one ( http://www.red-gate.com/messageboard/vi ... php?t=2088 )
  
  As far as a release date goes, you should be seeing the full version of SQL Dependency Tracker before the end of May - sorry I can't be more precise. I'll post a more concrete date as soon as I have one.
  
  Cheers,
  Dan

  Dan J Archer April 12, 2006 06:26

  - 0 +
• 
  Just a quick update: after looking into these memory issues, we're pretty sure we've traced the problem to the Orthogonal layout. With large graphs (more than a few hundred objects), Orthogonal's memory consumption gets disproportionately vast.
  
  Also Orthogonal isn't much use for very large graphs; as can be seen from one of the screenshots on this forum, there's so much connection routing going on and a few pinprick clusters of nodes.
  
  So for the final release we're only enabling Orthogonal layout for graphs of 500 objects or less. This is a bit of a workaround, but should avoid anyone suddenly losing a gig of memory for no readily apparent reason.
  
  Thanks for the feedback, this one was a good one to track down.
  
  Cheers,
  
  Dan

  Dan J Archer April 27, 2006 07:33

  - 0 +

Add comment

Please sign in to leave a comment.