![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Quick Survey Topic Summary: Created On: 14-Jul-2006 20:46 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Quick Survey
What is the largest module in your DOORS Database? # of Objects, Inlinks, Outlinks, etc. What effect does this module have on your PC's memory, processor speed, etc.? Thank you in advance for your replys... Craig M. Forant ------------------------- Craig Forant me@craigforant.com |
|
![]() |
|
![]() |
|
2500 objects; 7800 outlinks - inlinks doesn't affect performance.
A bit slower to open and save. If you have a lot of history, then will be slower. The greater the ping time between client and server, the more noticeable the effect on opening, closing and saving. On open the server sends a copy of a module to the client and back at saves. Hence the more object, outlinks and history the greater the performance impact. To mitigate you can baseline or split the modue sections into individual modules. In addition, if you have shareable edit set: the greater the number of sections set-up; the greater the performance impact. Ewen Miller |
|
![]() |
|
![]() |
|
We have 9,500 objects with 14,500 outlinks.
Module load time is good -- usually about 5 seconds. DOORS starts out at 35,000K for memory on my machine (no modules open), and jumps to 76,000K when I open that module. That number continues to increase as I scroll through the module. (Could be string table consuming memory.) Closing the module takes me back down to 55,000K. As a sidenote, we have a lot of tables (~4000 objects worth of them), and I have found the "Display All Table Cells" option in filters to be so slow as to be unusable. I don't know if anybody else has had this experience. Overall performance has been very good though. Kevin Edited: 17-Jul-2006 at 22:52 by Kevin James |
|
![]() |
|
![]() |
|
Ha ha.. .I have all you beat by a good margin.
The largest module I have been working with have these specs. - 70,013 objects (no DOORS tables) - 301,023 links going through it meaning outgoing and incoming Opening this module will consume about 1 gig of ram. The only problem I have is baselining the module in DOORS 7.1 since during a baseline all the links are also baselined, and links are cost a lot of real-estate. I wish there was a way to turn this off during the baseline besides temporarily deleting the links before a baseline. ------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
HHmmmmm,
We have two modules that spring to mind, largest number of objects: 75000, no links and is ok to work with. most problematic: 6000 objects, each is a shareable section, links are 99% in links. It the number of shareable sections that make this one painful, load time varies from 3 to 20 minutes depending on system load. ------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
Our biggest problem module contains about 15000 objects and about 6000+ outlinks.
It looks like shareable edit may be most of our problem. There are several hundred shareable sections in this particular module. It takes a ton of RAM/Page File to open and work with this file. Also, it seems that not baselining our module in a while affects this performance as well. (Thanks Ewen) On a side note...Our largest performance problem occurs when exporting this module to HTML. Because of the way the links are setup across projects, our export takes 6+ hours and eventually fails because of the PC's inability to handle the large memory swapping. The next question would probably be, how to improve a module's performance once it has been setup for sharing. Can the creation of shareable sections be reversed? If so, how well does it work? Thanks for the input. I love this community. ------------------------- Craig Forant me@craigforant.com |
|
![]() |
|
![]() |
|
You asked>> Can the creation of shareable sections be reversed? If so, how well does it work?
Shareable Edit... My understanding is that if you have selected shareable edit for, let's say 100 seperate sections, then you have just created 100 seperate files in the database. Setting these to shared is accomplished by unchecking Inherit from Parent in the object Access tab. It's easy to get back to the 'functionality' of 'Not Shareable' by re-checking all the 'Inherit from Parent ' boxes on the Access Tab of each property. (accomplished much quicker by DXL...) I have never actually looked, but I don't see performance return when I disable sharing. So I don't THINK that the database gets put back together when you do this. Does anybody know for sure if all those files remain in the database or does DOORs magically 'rebuild' a single module? |
|
![]() |
|
![]() |
|
Customer support have a DXL script called "set access to inherited" which will reset your sections. You can request it from them. As always these scripts are unsupported but this is a tried and tested script.
In order to complete the task you then need to open the module in question in full edit mode and do a save. This rolls the contents of the small section files into the main module files, which should then get you some performance improvement. Regards Mandy |
|
![]() |
Telelogic DOORS
» General Discussion
»
Quick Survey
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.