Attribute DXL: always refreshing when scrolling

Hello,

I wrote some attribute dxl for comparing attribute values between baselines and redlining them (thanks to Tony Goodman, btw ;-)).

However, although it's attribute dxl, it's refreshing all the time when scrolling, making it veeery slooow.

I already checked if a null value is set, or other things mentioned in this forum, but nothing helped.

Do you have any idea for any reasons for this recalculation?

Best regards,
Hardy
GerhardS - Tue Apr 02 10:21:07 EDT 2013

Re: Attribute DXL: always refreshing when scrolling
llandale - Tue Apr 02 11:01:37 EDT 2013

You can expect new calculations as you scroll down as the newly displayed objects do not yet have a value calculated. You should not see "refreshing" if you then scroll back up since these objects indeed already have a value calculated.

If it is recalculating when you scroll back up then I have some serious things to learn.

If it is very slow when originally scrolling down then either
  1. the code is ineffecient; possibly opening another module and also then closing it. Thus, each object displayed opens and closes.
  2. you can violate the natural laws of the universe and have the DXL code calculate it once for every object in the module. That is tricky.

-Louie

Re: Attribute DXL: always refreshing when scrolling
Jagtattoo - Tue Apr 02 12:34:57 EDT 2013

Hello Hardy,
Is it possible for you to convert this layout DXL to an Attribute DXL? This way, it will calculate the values for objects when the module is loaded, and then never update again unless the user specifically commands the DXL to update. I've done this in the past to expedite window scrolling.

Kind regards,
John

Re: Attribute DXL: always refreshing when scrolling
GerhardS - Wed Apr 03 01:53:11 EDT 2013

Jagtattoo - Tue Apr 02 12:34:57 EDT 2013
Hello Hardy,
Is it possible for you to convert this layout DXL to an Attribute DXL? This way, it will calculate the values for objects when the module is loaded, and then never update again unless the user specifically commands the DXL to update. I've done this in the past to expedite window scrolling.

Kind regards,
John

I'm a bit confused now. Actually, I understood (from other threads) that attribute DXL is calculated once when opening a module, and then on request (by using the respective menu function). That's why I assume the observed behaviour of my code to be somehow incorrect.

However, if I understand Louie's remarks correctly, then even attribute DXL is recalculated as soon as new objects come into display, for instance, when scrolling. Is this right?

  • Hardy

Re: Attribute DXL: always refreshing when scrolling
OurGuest - Wed Apr 03 07:25:23 EDT 2013

GerhardS - Wed Apr 03 01:53:11 EDT 2013
I'm a bit confused now. Actually, I understood (from other threads) that attribute DXL is calculated once when opening a module, and then on request (by using the respective menu function). That's why I assume the observed behaviour of my code to be somehow incorrect.

However, if I understand Louie's remarks correctly, then even attribute DXL is recalculated as soon as new objects come into display, for instance, when scrolling. Is this right?

  • Hardy

There is a possibility that your script is setting attribute value to null and therefore value is recalculated.

Re: Attribute DXL: always refreshing when scrolling
GerhardS - Wed Apr 03 10:53:23 EDT 2013

OurGuest - Wed Apr 03 07:25:23 EDT 2013
There is a possibility that your script is setting attribute value to null and therefore value is recalculated.

Well, the script calculates differences, and if there are no differences, then the result is empty: 

obj.attrDXLName = stringOf(bufDiffOut)

 


However, I already tried to explicitly check for null or empty string, and to not perform an assignment at all in that case, but this did not make any difference.

 

Re: Attribute DXL: always refreshing when scrolling
GerhardS - Wed Apr 03 11:04:12 EDT 2013

llandale - Tue Apr 02 11:01:37 EDT 2013
You can expect new calculations as you scroll down as the newly displayed objects do not yet have a value calculated. You should not see "refreshing" if you then scroll back up since these objects indeed already have a value calculated.

If it is recalculating when you scroll back up then I have some serious things to learn.

If it is very slow when originally scrolling down then either

  1. the code is ineffecient; possibly opening another module and also then closing it. Thus, each object displayed opens and closes.
  2. you can violate the natural laws of the universe and have the DXL code calculate it once for every object in the module. That is tricky.

-Louie

Louie,

> llandale wrote:
> You can expect new calculations as you scroll down as the newly displayed objects do not yet have a value calculated.

well, that's not what I understood up to now. I thought that the values were calculated when opening the module, not during scrolling. But if I understand you correctly, this my understanding is incorrect?

> You should not see "refreshing" if you then scroll back up since these objects indeed already have a value calculated.

indeed, when scrolling back and forth again, down to the point where I already have been, no further delays are encountered.

> If it is recalculating when you scroll back up then I have some serious things to learn.

yeah, things are not so bad ;-)

> If it is very slow when originally scrolling down then either
> # the code is ineffecient; possibly opening another module and also then closing it. Thus, each object displayed opens and closes.

With some performance testing I found out that the baseline loop is not very expensive, however, the "load" command is. I therefore optimized the structure, but this did not improve the overall performance significantly.

> # you can violate the natural laws of the universe and have the DXL code calculate it once for every object in the module. That is tricky.

I love tricky solutions, but actually - as I mentioned above - I expected DOORS to do exactly that when opening the module...

  • Hardy

Re: Attribute DXL: always refreshing when scrolling
llandale - Wed Apr 03 12:19:35 EDT 2013

Layouts re-calculate at a rediculous rate -I once measure 10 times per second- and are hopeless except for the simplest calculations. I strongly prefer Attr-DXL although that seems to be a minority opinion.

Attr-DXL is interpreted when the module is opened or when you modify the code. This generally doesn't matter to you unless you are using #include statements and debugging code. "Modify" means it actually has to change, such as adding a space after an include statement.

Attr-DXL is calculated for an object when:
In DOORS v8:
  • when the value is requested and it currently has a null value
  • In version 8 I recommended having attr-DXL set the value to a space " " instead of null in order to prevent contant re-calculation.
In DOORS v9
  • Louie best guess: the value is requested when it has not yet been calculated since module open or when set to null on-demand.
I think the following is true, perhaps someone will please prove or disprove:
  • I'm suggesting that, I think, a null value is NOT continually re-calculated in v9. The space advice no longer applies. I think that when the value is set to null FROM an attr-DXL, it is not re-calculated; but when it is set to null from an on-demand program (such as tools menu >Reset command), then it is indeed recalcaulated next time it is retrieved. If so, cudos to the development team for this dramatic improvement.

In any event, scrolling down while displaying an Attr-DXL should be slow as the newly displayed values have not yet been calculated since the module was open, but then scrolling back up should be fast since the value is retrieved and not re-calculated.

In your baseline case, I cannot help but think your attr-DXL looks like this:
  • Figure out which baseline
  • "load" that baseline
  • find the object in the baseline with the same AbsNo as this "obj".
  • display value from baseline
  • close baseline

If so, the continual open-close is killing performance.

My violate-natural-laws-of-universe suggestion would result in an Attr-DXL that looks like this:
  • for every o in mod do
    • Figure out which baseline
    • if the baseline is not yet loaded
      • then "load" that baseline; keep track that we loaded it
    • find the object in the baseline with the same AbsNo as this "o".
    • display value from baseline
  • For each Baseline we loaded herein
    • close baseline

So, when the FIRST attr-value is requested then ALL of them are calculated. The SECOND one requested will result in retrieval since it is already calculated (by the first request).

The "violation" is that attr-DXL has the natural context of just this "obj"; yet we artificially expand it to calculate them all.

-Louie

I remind folks that attr-DXL values are not stored; thus an att-DXL displayed in a Baseline will calcuate the CURRENT value (not the one that existed when it was baselined) which is generally detrimental. Perhaps before baselining you save to "text" attributes copies of all the attr-DXL values.

Re: Attribute DXL: always refreshing when scrolling
GerhardS - Thu Apr 04 02:47:52 EDT 2013

llandale - Wed Apr 03 12:19:35 EDT 2013
Layouts re-calculate at a rediculous rate -I once measure 10 times per second- and are hopeless except for the simplest calculations. I strongly prefer Attr-DXL although that seems to be a minority opinion.

Attr-DXL is interpreted when the module is opened or when you modify the code. This generally doesn't matter to you unless you are using #include statements and debugging code. "Modify" means it actually has to change, such as adding a space after an include statement.

Attr-DXL is calculated for an object when:
In DOORS v8:

  • when the value is requested and it currently has a null value
  • In version 8 I recommended having attr-DXL set the value to a space " " instead of null in order to prevent contant re-calculation.
In DOORS v9
  • Louie best guess: the value is requested when it has not yet been calculated since module open or when set to null on-demand.
I think the following is true, perhaps someone will please prove or disprove:
  • I'm suggesting that, I think, a null value is NOT continually re-calculated in v9. The space advice no longer applies. I think that when the value is set to null FROM an attr-DXL, it is not re-calculated; but when it is set to null from an on-demand program (such as tools menu >Reset command), then it is indeed recalcaulated next time it is retrieved. If so, cudos to the development team for this dramatic improvement.

In any event, scrolling down while displaying an Attr-DXL should be slow as the newly displayed values have not yet been calculated since the module was open, but then scrolling back up should be fast since the value is retrieved and not re-calculated.

In your baseline case, I cannot help but think your attr-DXL looks like this:
  • Figure out which baseline
  • "load" that baseline
  • find the object in the baseline with the same AbsNo as this "obj".
  • display value from baseline
  • close baseline

If so, the continual open-close is killing performance.

My violate-natural-laws-of-universe suggestion would result in an Attr-DXL that looks like this:
  • for every o in mod do
    • Figure out which baseline
    • if the baseline is not yet loaded
      • then "load" that baseline; keep track that we loaded it
    • find the object in the baseline with the same AbsNo as this "o".
    • display value from baseline
  • For each Baseline we loaded herein
    • close baseline

So, when the FIRST attr-value is requested then ALL of them are calculated. The SECOND one requested will result in retrieval since it is already calculated (by the first request).

The "violation" is that attr-DXL has the natural context of just this "obj"; yet we artificially expand it to calculate them all.

-Louie

I remind folks that attr-DXL values are not stored; thus an att-DXL displayed in a Baseline will calcuate the CURRENT value (not the one that existed when it was baselined) which is generally detrimental. Perhaps before baselining you save to "text" attributes copies of all the attr-DXL values.

Thanks a lot for the great explanation, Louie!

Btw: Do you see any chance to de/serialize handles, such as the "modBaseline" handle from: 

Module modBaseline = load(modCurrent, (Baseline doCurrent->"baseline"), false)


i.e., to store the handle, for instance, in the user config space of DOORS, and to restore it from there?
Especially for attrib DXL this would be helpful, as I could hand over information between the different obj contextes, without the need for any other helper attributes or so.

 

 

  • Hardy

 

 

Re: Attribute DXL: always refreshing when scrolling
Mathias Mamsch - Thu Apr 04 04:12:38 EDT 2013

GerhardS - Thu Apr 04 02:47:52 EDT 2013

Thanks a lot for the great explanation, Louie!

Btw: Do you see any chance to de/serialize handles, such as the "modBaseline" handle from: 

Module modBaseline = load(modCurrent, (Baseline doCurrent->"baseline"), false)


i.e., to store the handle, for instance, in the user config space of DOORS, and to restore it from there?
Especially for attrib DXL this would be helpful, as I could hand over information between the different obj contextes, without the need for any other helper attributes or so.

 

 

  • Hardy

 

 

I showed a technique for passing information between layout contexts here:

http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14891453

The big challange is to reliably detect, when the DXL context hosting the information ends. In the example I gave, I rely on the fact that the close event of a GUI is reliable.

Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS