While DXL is similar to C++ there are some very distinct differences. One is that DXL is interpreted. Because of this, variable declaration should be treated differently than with an interpreted language. While what I am about to share may have been addressed in recent version, it was still true in DOORS 8.1. In C++ classrooms and text books, developers are encouraged to declare variables in the program structures where they are used. The compiler is smart enough to know that the developer only wants memory allocated once. In interpreters, variable declarations assign memory every time they are encountered by the interpreter. This means that if you declare a variable inside a loop, memory is allocated for that variable every time the interpreter passes through the loop. For example: for (i=0; i<1000; i++) { int j . . . } This code will allocate memory for j 1000 times. In small programs with small loops this will be inconsequential. In programs with large loops and/or large data structures, this can be catastrophic. Back when we were using DOORS 8.1 I fixed mysterious DOORS crashes simply by moving variable declarations outside the loops. Since function variables are created in the stack that gets created for the variables, this problem does not occur with function variables because when the function is returned stack memory for that function is restored. To eliminate this issue, I declare all variables either globally or at the function level. If this is no longer true, I am sure someone will correct me. -David Bond David_G_Bond - Tue Feb 24 14:16:51 EST 2015 | |||||||||||||||||||||||||
Re: DXL is interpreted I am pretty sure, there is no difference between declaring variables inside or outside of a the loop. As far as I know the DXL interpreter (and I know it quite a bit), is that DXL like Java or Python translates the source code to byte code before executing it. During this translation, variables get assigned their address on the stack. For me that means, that there is no allocation of memory. The stack is by definition pre-allocated memory. The access to the variable (regardless of where it was defined) always works through the same mechanism. I can come up with no code, where I would assume that the stack layout changes during runtime, even for simple arrays (that live on the stack in DXL and can by dynamically allocated), the array handle gets a fixed stack address, but the memory is allocated at the end of the stack! You can see this with the following example:
int i;
for (i = 1; i < 10; i++) {
int ar[i];
int j = 0;
print "I = " i " J=" j "(" ((addr_ (&j)) int) ")\n"
print "&ar=" ((addr_ (&ar)) int) "\n" // stack address of array handle
print "ar=" ((addr_ (ar)) int) "\n" // start of array memory
print "ar[0]=" ((addr_ (&(ar[0]))) int) "\n" // address of first array item
print "ar[i-1]=" ((addr_ (&(ar[i-1]))) int) "\n\n" // address of last array item
}
When you run this code and interpret the output, you get the following:
As you can see, the the address of all variables is fixed in memory. The simple array ALSO has a fixed address, but its contents are initialized at the end of the stack in every run. You can see that the content of the array variable ar changes with every loop iteration to the new start of the initialized array. Actually I think this code uncovers a stack leak with simple arrays, since you would expect the old contents of the array to be erased from the stack after the loop and the newly initialized array to take the same space as the old one. Conclusion: I can agree that with simple arrays you shoud definitiely declare them outside the loop. For all variables that allocate heap memory its also true, but I guess that is clear. Buffers for example live on the stack (or their 'handle') but their internal data structure lives on the heap. So here of course it matters, wheter or not you allocate / deallocate the memory inside or outside a loop. Regards, Mathias | |||||||||||||||||||||||||
Re: DXL is interpreted Mathias, Thank you for your response. As I said in my first post, we ran into problems when using DOORS 8.1. The specific example was one where the script looped through the objects in a module and looped through the links in each object, declaring a Module attribute in the loop for the links. Then the script opened the linked module in read mode and retrieved data. We actually did 2 things to improve the performance and eliminate the memory leaks. We moved the module declaration out of the loops and only opened the module if it was not already open. Perhaps it was the repeated opening of the module that was the issue and not the module variable declaration. - David Bond | |||||||||||||||||||||||||
Re: DXL is interpreted David_G_Bond - Wed Feb 25 11:53:13 EST 2015 Mathias, Thank you for your response. As I said in my first post, we ran into problems when using DOORS 8.1. The specific example was one where the script looped through the objects in a module and looped through the links in each object, declaring a Module attribute in the loop for the links. Then the script opened the linked module in read mode and retrieved data. We actually did 2 things to improve the performance and eliminate the memory leaks. We moved the module declaration out of the loops and only opened the module if it was not already open. Perhaps it was the repeated opening of the module that was the issue and not the module variable declaration. - David Bond I don't believe issuing a "read" command inside a loop is particulary slow, compared to just trying to retrieve the Module hand via "module". But I wonder if it MIGHT be slow if you command it to open the "Standard view" in the read command as it will load the view even if already loaded. I seem to recall some problems years ago like you have outlined. But as you I put all declarations at the module level. It is a lot less confusing, especially if you use the same variable outside as inside.
Yuuuuuck. | |||||||||||||||||||||||||
Re: DXL is interpreted David_G_Bond - Wed Feb 25 11:53:13 EST 2015 Mathias, Thank you for your response. As I said in my first post, we ran into problems when using DOORS 8.1. The specific example was one where the script looped through the objects in a module and looped through the links in each object, declaring a Module attribute in the loop for the links. Then the script opened the linked module in read mode and retrieved data. We actually did 2 things to improve the performance and eliminate the memory leaks. We moved the module declaration out of the loops and only opened the module if it was not already open. Perhaps it was the repeated opening of the module that was the issue and not the module variable declaration. - David Bond Hi David, i just wanted to point out, that for variables like "int" there is no performance problem (like your post suggested) - not under DOORS 8.1 and not in recent DOORS versions - so I would not sign a petition to always declare ALL variables at top of the function. A lot of times, when trying to solve one of those "mystic" DOORS issues, that suddenly go away, after doing some seemingly unrelated changes, one comes to over-generalized receipes about what to do and not to do in DXL. Its possible that there is an Issue in DOORS 8.1 with reading attributes or links or something like that and moving a statement independent from the loop out of the loop can bring a performance increase and reduce a memory leak. But I wanted to point out clearly that this is not an issue of the 'declaration' inside or outside a loop. This is almost certainly related to moving a leaky statement (not a simple declaration) outside the loop but unless I see an example of a simple declaration slowing down a loop, I will not believe that it brings any advantage to move declarations outside of loops. Regards, Mathias | |||||||||||||||||||||||||
Re: DXL is interpreted Hi everyone, I have worked with Doors 5.x, Doors 8.1, and Doors 9.2 and have a lot of complicated DXL code and have found some of the following actions can create memory and performance issues:
| |||||||||||||||||||||||||