Performance

• 
  Hi Jon,
  
  
  Thanks for reporting this. Unfortunately there is a known performance issue in the beta when clicking on the diagram (embarrassingly enough). We just had a rogue event in there, which has now been brought under control. You should find the final release is much quicker, however I'd be interested in knowing roughly how many objects are on your diagram if you could give me that information please? Then I can test SQL Dependency Tracker on a comparably sized database here and see how it performs, and if there are any other improvements we can make.
  
  
  Many thanks,

  Bart Read April 04, 2006 10:51

  - 0 +
• 
  Hi Jon,
  
  As another work around, in the beta it's possible to avoid this CPU thrashing after having added all objects to your project by clicking one in the Objects on Diagram list first, before you click on the diagram itself. The bug in question manifests when you select or deselect a large number of objects using either the diagram itself or the toolbar buttons. If you do your selection from the Objects on Diagram list (eg. Ctrl-A to select all) then it doesn't show up.
  
  As Bart says, this is a dumb bug and, rest assured, this will certainly be fixed for the final release. In our latest test builds it's already gone. Thanks for reporting it tho, and for your patience with the beta!
  
  All the best,
  Dan

  Dan J Archer April 04, 2006 12:39

  - 0 +
• 

  Bart Read wrote:

  I'd be interested in knowing roughly how many objects are on your diagram if you could give me that information please? Then I can test SQL Dependency Tracker on a comparably sized database here and see how it performs, and if there are any other improvements we can make.

  Since that information is useful to you, it would be nice if the GUI had an easy way for me to determine how many objects are in the diagram. If it does, I can't find it.
  
  I exported to XML and grepped the number of <Object> occurrances. 4,223 objects, according to this method.
  
  I uploaded an exported PNG of my diagram to http://www.jonrobertson.net/DependencyTracker.png. I don't know about you, but that's just not very useful to me. Particularly when trying to navigate around is very slow (even using the diagram list, it isn't fast enough to be useful to me).
  
  By the way, it took my machine over half an hour to generate that diagram (Orthogonal). I wish I'd actually timed it. But it was definitely over 30 minutes.
  
  I'll echo other posts that I've read: When looking for a Dependency Tracker, I'm not looking for a fancy diagraming tool that'll let me bounce from one object to another. I'm looking for something that will let me easily and quickly determine what the dependencies are, and what affect removing a single constraint/column/table/stored proc/func/etc will have on the rest of the schema.

  JonRobertson April 04, 2006 14:45

  - 0 +
• 
  Hi Jon,
  
  Thanks for that. That's a serious database.
  
  Bugs in the beta aside, I can be honest and say you're working with an order of magnitude more objects at a time than we anticipated. I'd be interested to know how many people have to deal with such large schemas. We may need to try and squeeze in some optimisation to make things a bit more quicker for people in your position.
  
  You're quite right, orthogonal is lousy for such a gargantuan number of objects. It's an interesting view for smaller datasets, but we wouldn't recommend it for schemas of the magnitude you've got to deal with. That's probably not going to change for the final release. Perhaps we should make it a bit more obvious that some layouts are a Bad Plan for huge numbers of objects.
  
  Sounds like you're looking to analyse and record the impact of a potential change - this is one of the key (if not the key) tasks we're aiming to make easy with SQL Dependency Tracker. Perhaps you'd take a look at my post on this thread, and see what you think: http://www.red-gate.com/messageboard/vi ... php?t=2086
  
  Regards,
  
  Dan

  Dan J Archer April 05, 2006 09:24

  - 0 +
• 
  Well, depending on how you did it, grepping on <object> tags could over-inflate the numbers, given that the tag <object> is used as a child of <uses> and of <used by>, which are children of <object> again.
  
  Grepping on <object> in general would actually give, I think, a general count of the number of links or dependencies.
  
  - alphadog

  alphadog April 05, 2006 11:57

  - 0 +
• 

  alphadog wrote:

  Well, depending on how you did it, grepping on <object> tags could over-inflate the numbers, given that the tag <object> is used as a child of <uses> and of <used by>, which are children of <object> again.
  
  Grepping on <object> in general would actually give, I think, a general count of the number of links or dependencies.

  That makes complete sense. But I don't know how else to determine the number of objects in my diagram.
  
  I can easily report back the number of Tables, Procedures, etc, in the database. But I'm not clear on which objects SDT currently tracks.
  
  Running this query:

  select type, count(*) as [Count]
  from sysobjects
  group by type
  

  Gives these results:

  type Count       
  ---- ----------- 
  TR   23
  U    161
  F    281
  C    79
  S    19
  K    201
  D    468
  FN   4
  TF   2
  V    51
  P    147
  

  JonRobertson April 05, 2006 18:22

  - 0 +
• 
  The only way I can think of knowing how many object RGDT sees would be maybe an xml query (xpath) on the export. Something like count(//Database/Object), which would be a count of <object>s attached to <database>.
  
  Unfortunately, my XML editor is on the fritz, so I can't verify if this is correct.
  
  - alphadog[/i]

  alphadog April 06, 2006 08:49

  - 0 +
• 
  We did want to add a count of objects in the database and on the diagram - sadly this is one of the small features that hasn't made this release. It's on the list for next time though!
  
  All the best,
  
  Dan
  
  ====================
  Dan J Archer
  SQL Dependency Tracker Project Lead
  Red Gate Software

  Dan J Archer April 26, 2006 07:03

  - 0 +

Add comment

Please sign in to leave a comment.