![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Speeding up layout DXL Topic Summary: Created On: 18-Oct-2007 17:17 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: My approach is: If I don't need recursion, I make the declarations global and minimize use of string assignments. Declaration as globals may fly in the face of computer scientist but I assume globals are fasters. Even if you do need recursion, some of the variable need not be declared during each iteration (for example, string s). I suspect length of variables names isn't a big factor. Some users use Buffers, I have not seen much benefits in layout dxl for buffers but I am sure there are exceptions to this observation about buffers. Don't use skip list unless you absolutely have to use skip list. You can also minimize some of the test (ie., if statements) if you know your data well enought to know the test are not required. Also, If you don't need richText don't use the probeRichAttr_ function and displayRich. Instead use probeAttr_ and display. Also, the function other."Object Text" may be faster than the probe function but I have no emperical evidence to support these claims. Don't define any variable that isn't absolutely necessary. (i.e, the wizard creates several variables that are not always used.) A single display of a long string may be faster than multiple displays of short strings. If there are no links don't even bother making any declarations of variables. | |
![]() |
|
Any quick advice for writing layout DXL that runs quickly? I'm starting with some wizard-generated code (which is rather incomprehensible out of the box) and trying to morph it into something useful and understandable to me. One of the first things I'm doing is substituting more meaningful variable names and adding comments, but even that seemed to slow it down. Is the code being interpreted behind the scenes? I'm trying to peel out some of the hooks that appear to be a consequence of the wizard, but maybe some of the strange organization is on purpose. |
|
![]() |
|
![]() |
|
The wizard generated code has its appearance because of recursion.
Even if the resulting code isn't recursive the basic code is the same as recursive code. Note: the integer value depth is all about recursion and how many levels of iteration. Therefore to speed up the code if you don't need the recursive characteristic -- remove the recuseive nature. Edited: 18-Oct-2007 at 17:59 by ron lewis |
|
![]() |
|
![]() |
|
Ron-
I noticed the recursive aspect and depth was one of the first things I peeled out (not that it amounted to much). My question really was more one of how in general to write layout code to make it run faster. I have some big modules and response can get pretty pokey. Do you have any rules of thumb for speeding things up??? For instance changing variable names from "l" to "linkToTheSource" makes it easier for me to read the code but does this have a negative impact?
Thanks
Al
|
|
![]() |
|
![]() |
|
My approach is:
If I don't need recursion, I make the declarations global and minimize use of string assignments. Declaration as globals may fly in the face of computer scientist but I assume globals are fasters. Even if you do need recursion, some of the variable need not be declared during each iteration (for example, string s). I suspect length of variables names isn't a big factor. Some users use Buffers, I have not seen much benefits in layout dxl for buffers but I am sure there are exceptions to this observation about buffers. Don't use skip list unless you absolutely have to use skip list. You can also minimize some of the test (ie., if statements) if you know your data well enought to know the test are not required. Also, If you don't need richText don't use the probeRichAttr_ function and displayRich. Instead use probeAttr_ and display. Also, the function other."Object Text" may be faster than the probe function but I have no emperical evidence to support these claims. Don't define any variable that isn't absolutely necessary. (i.e, the wizard creates several variables that are not always used.) A single display of a long string may be faster than multiple displays of short strings. If there are no links don't even bother making any declarations of variables. Edited: 19-Oct-2007 at 12:57 by ron lewis |
|
![]() |
|
![]() |
|
If you have a lot of information to display in traceability columns, performance can be poor because DOORS is working hard to refresh the data as you scroll around the module.
One of the biggest factors in this is the overhead of opening other modules. One solution is to use DXL attributes instead of layout dxl. These are not recomputed every time you scroll so other modules are not opened and performance is better. ------------------------- Tony Goodman http://www.smartdxl.com Edited: 19-Oct-2007 at 08:24 by Tony Goodman |
|
![]() |
|
![]() |
|
I find that there are huge speed improvements in large modules by using Buffers instead of strings and using the tempStringOf(Buffer b) command to minimize the size of the string table. Just be sure to delete the buffer when you're done with it. If you have some code to open a module in layout(or attribute) DXL, never close it again in the code. Otherwise for every object that other module has to be loaded.
But as Tony said, your best bet is to use attribute DXL since it doesn't have to be recomputed with every scroll. Just use the wizard to get a basic idea of the code and trim it down from there. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
Telelogic DOORS
» General Discussion
»
Speeding up layout DXL
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.