Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
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
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Pekka Mäkinen, on Tuesday, October 28, 2008 10:39 PM

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.
 16-Oct-2008 07:55
User is offline View Users Profile Print this message


Peter Dawson

Posts: 14
Joined: 21-Jul-2008

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
Report this to a Moderator Report this to a Moderator
 16-Oct-2008 08:25
User is offline View Users Profile Print this message


Pekka Mäkinen

Posts: 276
Joined: 18-Mar-2004

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/
Report this to a Moderator Report this to a Moderator
 16-Oct-2008 14:37
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 120
Joined: 16-Jan-2008

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
Report this to a Moderator Report this to a Moderator
 16-Oct-2008 23:55
User is offline View Users Profile Print this message


Peter Dawson

Posts: 14
Joined: 21-Jul-2008

double post....please delete

-------------------------
Peter Dawson
Engineering Tools Support Group
Boeing Australia Limited

Edited: 17-Oct-2008 at 00:00 by Peter Dawson
Report this to a Moderator Report this to a Moderator
 16-Oct-2008 23:59
User is offline View Users Profile Print this message


Peter Dawson

Posts: 14
Joined: 21-Jul-2008

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
Report this to a Moderator Report this to a Moderator
 17-Oct-2008 12:25
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

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
Report this to a Moderator Report this to a Moderator
 23-Oct-2008 00:13
User is offline View Users Profile Print this message


Peter Dawson

Posts: 14
Joined: 21-Jul-2008

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
Report this to a Moderator Report this to a Moderator
 23-Oct-2008 14:29
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

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
Report this to a Moderator Report this to a Moderator
 23-Oct-2008 18:47
User is offline View Users Profile Print this message


Pekka Mäkinen

Posts: 276
Joined: 18-Mar-2004

Answer 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.

-------------------------
Pekka.Makinen@softqa.fi
SoftQA Oy -http://www.softqa.fi/
Report this to a Moderator Report this to a Moderator
 28-Oct-2008 14:16
User is offline View Users Profile Print this message


Andrew Tagg

Posts: 151
Joined: 26-Oct-2004

Nice work Pekka, thanks

-------------------------
Andrew Tagg
Thales Air Systems, Melbourne
Australia.
andrew.tagg@thalesatm.com
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.