![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Module causing unexplained DOORS memory usage Topic Summary: Created On: 16-Oct-2008 07:55 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Did some experiments on this issue on my own laptop, in some other environment the actual times might be different, but maybe the differences between String type and Text type are similar. I used a script two create two modules with 4400 objects (400 headings and 4000 objects under those headings) and with about 200 attributes, one module had String type attributes and the other module had Text type attributes. In both modules the objects and attributes had the same content, so the only difference between these two modules was the attribute type differences. My results were that the module with Text type attributes before baselining was much slower to save after creation and to re-open, the differences in time on these actions between the "String type" and "Text type" module were 60 - 100 fold. After baselining these modules both modules opened almost as rapidly in DOORS, the String module in 8 seconds and the Text module in 11 seconds. But after making one change to one object (in Object Text) in both modules, again differences in the saving times were enormous. My conclusion on these results is that a module which had this much objects and attributes was actually quite usable if the attributes were of String type. If the attributes were of Text type the module was usable only after baselining (to open), but if there were changes made and saved, then the waiting time was looooong. | |
![]() |
|
We have a DOORS 8.0 module with 3855 objects and total characters = 4,213,741 (according to Module Properties -> Statistics).
Whilst the module does not have a massive number of objects it does have 160 (mostly text) attributes. The module does contain triggers however I have observed the same behaviour as below when they are disabled. The default view contains no layout or attribute dxl columns. Not does it contain the module explorer. I am finding that when I open the module, DOORS 8.0 memory usage in task manager increases by 200MB (its currently sitting at 400,000K and when I close the module it goes back down to 197,000K). This large memory usage has the symptoms of: - Slow module loading; - Slow to change between edit modes; I can confirm that the process of opening a module is CPU intensive and not network intensive. I can't understand how a module that contains maybe 10MB of actual data can consume more than 20 times that in physical memory. Any suggestions? ------------------------- Peter Dawson Engineering Tools Support Group Boeing Australia Limited |
|
![]() |
|
![]() |
|
History. When the module loads objects it also loads the history. If you do not have baselined the module (which clears the history) recently it might have plenty of history changes.
------------------------- Pekka.Makinen@softqa.fi SoftQA Oy -http://www.softqa.fi/ |
|
![]() |
|
![]() |
|
I believe history is the culprit here too, but also think you can improve performance by making some of those "Text" attributes "String" attributes. Text takes up more space than String. I imagine that some of your text attributes can be string attributes, but of course, maybe that's not the case.
------------------------- Kevin Murphy http://www.baselinesinc.com |
|
![]() |
|
![]() |
|
double post....please delete
------------------------- Peter Dawson Engineering Tools Support Group Boeing Australia Limited Edited: 17-Oct-2008 at 00:00 by Peter Dawson |
|
![]() |
|
![]() |
|
The module had been baselined recently in an attempt to improve performance so I don't believe history is the issue.
I am suspicious that the large number of text attributes could be the cause of the problem. Certainly, most of the text attributes contain plaintext strings anyway. Does anyone know a way to change the type of an existing attribute whilst preserving the data. Does anyone have a script to do this? The script would have to create new string attributes for every text attribute. Copy the data in the text attribute to the new string attribute as a plaintext string. Delete the text attributes and rename the string attributes to the same name as the text attributes. I could write a script to do this. Would this methodolgy work? Do you think it would help with the memory issue? ------------------------- Peter Dawson Engineering Tools Support Group Boeing Australia Limited Edited: 17-Oct-2008 at 00:11 by Peter Dawson |
|
![]() |
|
![]() |
|
I don't have a script but it's fairly simple. Also I would recommend you making the new string attributes. Don't just loop through and change them all because I'm sure you have some things where text is preferred since string attributes cannot have newlines. Just loop through the ones you change. We also have a module with relatively few objects but it is extremely slow due to the number of attributes in the module.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
I presented this issue to some of the experts at the Australian TUGC. They said that the performance issues are most certainly a result of the large number of text attributes. They said that they said most modules begin to struggle with 50-60 text attributes, let alone 160!
From the user manual. Clearly the "Text" attribute brings with it, significant memory overheads. Text Attribute. A Text attribute type can include paragraphs (newline characters), and there is no restriction on the number of characters that can be entered. String Attribute. A String attribute type cannot include paragraphs (newline characters), and there is an upper limit of 968 on the number of characters that can be entered. The upper limit of 968 includes hidden characters and not just visible characters. For example, rich text contains hidden characters and these are included as part of the 968 characters; unicode and upper ASCII characters take up more internal storage space then plain ASCII characters. If you try to enter a value that contains more than 968 characters, an error will be reported, and the value will be truncated. If you need to enter a large number of characters, use a Text attribute as there is no restriction on the number of characters that can be stored in a Text attribute. ------------------------- Peter Dawson Engineering Tools Support Group Boeing Australia Limited |
|
![]() |
|
![]() |
|
Hi Peter, yep I remember Ian Zimmermann talking about this during his presentation. Would be interesting if you can convert some of those Text attr's into strings and see what improvement you get (perhaps in a copy of the mod to start with). Good luck.
------------------------- Andrew Tagg Thales Air Systems, Melbourne Australia. andrew.tagg@thalesatm.com |
|
![]() |
|
![]() |
|
Did some experiments on this issue on my own laptop, in some other environment the actual times might be different, but maybe the differences between String type and Text type are similar.
I used a script two create two modules with 4400 objects (400 headings and 4000 objects under those headings) and with about 200 attributes, one module had String type attributes and the other module had Text type attributes. In both modules the objects and attributes had the same content, so the only difference between these two modules was the attribute type differences. My results were that the module with Text type attributes before baselining was much slower to save after creation and to re-open, the differences in time on these actions between the "String type" and "Text type" module were 60 - 100 fold. After baselining these modules both modules opened almost as rapidly in DOORS, the String module in 8 seconds and the Text module in 11 seconds. But after making one change to one object (in Object Text) in both modules, again differences in the saving times were enormous. My conclusion on these results is that a module which had this much objects and attributes was actually quite usable if the attributes were of String type. If the attributes were of Text type the module was usable only after baselining (to open), but if there were changes made and saved, then the waiting time was looooong. ------------------------- Pekka.Makinen@softqa.fi SoftQA Oy -http://www.softqa.fi/ |
|
![]() |
|
![]() |
|
Nice work Pekka, thanks
------------------------- Andrew Tagg Thales Air Systems, Melbourne Australia. andrew.tagg@thalesatm.com |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.