Topic
  • 4 replies
  • Latest Post - ‏2013-09-21T06:20:01Z by mohaIBMDK
mohaIBMDK
mohaIBMDK
25 Posts

Pinned topic RBD 8.51.0 - why doing alot of full "building workspace" ?

‏2013-09-17T05:11:22Z |

In RBD 8.5.1.0 we have the same problem on several workstations - the "building workspace" is very often doing a full rebuild of all the EGL code, if we make a change in any single EGL source file. 

I would like to have some hint about criteria for doing the full build - to understand what is wrong in the setup.

Is the full rebuild related to:

- lack of memory ? we have 3 GB memory, and it looks as there is alot of free memory

- Windows environment ? We use Windows 2003 Server as development environment

- Virtual machines ? We use VMWare virtual machines

- RBD startup parameters ? We have default setup from installation

- too many changes in local history ? if we cleanup the local history (deleting the .metadata/..../.history folder)  if seems to disppear for some days

- too many open projects ? We have 15 projects open - both TUI and web projects. We have tried to close some of the projects but seems with no luck

We have  also tried to make a "clean workspace" build, but it seem to have no effect.

As this full rebuild takes about 1 hour, and is repeated as soon as we close down and re-open RBD - it's rather frustrating.

Please hints for this problem - thanks alot.

TIA

Morten Hansen, IBM Denmark

  • markevans
    markevans
    3034 Posts
    ACCEPTED ANSWER

    Re: RBD 8.51.0 - why doing alot of full "building workspace" ?

    ‏2013-09-20T17:26:00Z  
    • Hsieh
    • ‏2013-09-20T16:21:33Z

    Hi Moha,

    a question:

    These EGL Source file are referenced by another EGL Source file ?   If YES, this could cause the rebuild of other EGL Source.  This has happened to me.

    Second, check this:

    on Window >> Preferences >> EGL >> Generation, unmark the options:

    - If necessary, invoque a build before generating output.

    - Generate after build

    If it didn't fix, you can try to create a new workspace and export/import projects

     

    Regards,

    Hsieh

     

    Morten,

    If I understood your question, it is related to the length of time a "building Workspace" takes and why it is triggered so often.

    One reason could be related to how Top Level Functions (or also known as standalone functions)  are processed.   A top level function is a standalone function that is within a source file, but not contained in a program, library, or service (e.g. between the Program/end) .    It was a common practice for VAGen migrated functions since all functions in VAGen were essentially independent and there was not a namespace in vAGen (imports/eGL Build Path).

    Anyway, the way the builder (actually we call it the compiler) works is that if a Top Level Function (TLF) is changed in a source file, then all the functions below it in the file are recompiled also.   Then if those functions were referenced in some other package/project, then those are rebuilt with the same processing in terms of position within a source file.     There are reasons we had to do "different" processing with TLFs mainly having to do with the fact that many times you want to validate them within the context of the program...not independently.

    As an example,  if you have a .egl source file that contains 100 Top Level Functions and you change the one that is physically the second one in the file.  When you save the file, it then rebuilds that function AND the following 98 functions.  If any of these 99 functions are referenced in the workspace (likely), then the build cascades to those functions to make sure all is still in sync..  Then it continues cascading until all references are rebuilt.    If you change the function that is physically the 98th one in the file, then it only rebuilds the 98, 99, and 100 functions and then cascades with this much smaller subset.

    All of this means a "simple" change in one top level function can trigger what looks like or could be the entire workspace being rebuilt...depending on how big the source files are with top level functions and what function was changed. .

    Now the good news is we did put a fix to help with performance in this scenario.   I don't believe it was shipped in 8.5.1 and therefore, it should be in 8.5.1.1 as well as 9.0.  It was originally shipped in 8.0.1.5.   (8.0.1.5 came after 8.5.1 if you are wondering..and this was a fix that originated in V8.0.1.

    The other option to look at is using EGLARs or Binary Projects.  Parts in an EGLAR are not rebuilt when a build is called for.  This will speed up the overall build time significantly.   It is a good practice to use particularly for common code.   V9.0 expanded our EGLAR support to allow the use of a libary (folder) to hold the EGLARs vs having to name each EGLAR individually.

    Mark

  • Hsieh
    Hsieh
    708 Posts

    Re: RBD 8.51.0 - why doing alot of full "building workspace" ?

    ‏2013-09-20T16:21:33Z  

    Hi Moha,

    a question:

    These EGL Source file are referenced by another EGL Source file ?   If YES, this could cause the rebuild of other EGL Source.  This has happened to me.

    Second, check this:

    on Window >> Preferences >> EGL >> Generation, unmark the options:

    - If necessary, invoque a build before generating output.

    - Generate after build

    If it didn't fix, you can try to create a new workspace and export/import projects

     

    Regards,

    Hsieh

     

  • markevans
    markevans
    3034 Posts

    Re: RBD 8.51.0 - why doing alot of full "building workspace" ?

    ‏2013-09-20T17:26:00Z  
    • Hsieh
    • ‏2013-09-20T16:21:33Z

    Hi Moha,

    a question:

    These EGL Source file are referenced by another EGL Source file ?   If YES, this could cause the rebuild of other EGL Source.  This has happened to me.

    Second, check this:

    on Window >> Preferences >> EGL >> Generation, unmark the options:

    - If necessary, invoque a build before generating output.

    - Generate after build

    If it didn't fix, you can try to create a new workspace and export/import projects

     

    Regards,

    Hsieh

     

    Morten,

    If I understood your question, it is related to the length of time a "building Workspace" takes and why it is triggered so often.

    One reason could be related to how Top Level Functions (or also known as standalone functions)  are processed.   A top level function is a standalone function that is within a source file, but not contained in a program, library, or service (e.g. between the Program/end) .    It was a common practice for VAGen migrated functions since all functions in VAGen were essentially independent and there was not a namespace in vAGen (imports/eGL Build Path).

    Anyway, the way the builder (actually we call it the compiler) works is that if a Top Level Function (TLF) is changed in a source file, then all the functions below it in the file are recompiled also.   Then if those functions were referenced in some other package/project, then those are rebuilt with the same processing in terms of position within a source file.     There are reasons we had to do "different" processing with TLFs mainly having to do with the fact that many times you want to validate them within the context of the program...not independently.

    As an example,  if you have a .egl source file that contains 100 Top Level Functions and you change the one that is physically the second one in the file.  When you save the file, it then rebuilds that function AND the following 98 functions.  If any of these 99 functions are referenced in the workspace (likely), then the build cascades to those functions to make sure all is still in sync..  Then it continues cascading until all references are rebuilt.    If you change the function that is physically the 98th one in the file, then it only rebuilds the 98, 99, and 100 functions and then cascades with this much smaller subset.

    All of this means a "simple" change in one top level function can trigger what looks like or could be the entire workspace being rebuilt...depending on how big the source files are with top level functions and what function was changed. .

    Now the good news is we did put a fix to help with performance in this scenario.   I don't believe it was shipped in 8.5.1 and therefore, it should be in 8.5.1.1 as well as 9.0.  It was originally shipped in 8.0.1.5.   (8.0.1.5 came after 8.5.1 if you are wondering..and this was a fix that originated in V8.0.1.

    The other option to look at is using EGLARs or Binary Projects.  Parts in an EGLAR are not rebuilt when a build is called for.  This will speed up the overall build time significantly.   It is a good practice to use particularly for common code.   V9.0 expanded our EGLAR support to allow the use of a libary (folder) to hold the EGLARs vs having to name each EGLAR individually.

    Mark

  • Hsieh
    Hsieh
    708 Posts

    Re: RBD 8.51.0 - why doing alot of full "building workspace" ?

    ‏2013-09-20T23:49:12Z  
    • markevans
    • ‏2013-09-20T17:26:00Z

    Morten,

    If I understood your question, it is related to the length of time a "building Workspace" takes and why it is triggered so often.

    One reason could be related to how Top Level Functions (or also known as standalone functions)  are processed.   A top level function is a standalone function that is within a source file, but not contained in a program, library, or service (e.g. between the Program/end) .    It was a common practice for VAGen migrated functions since all functions in VAGen were essentially independent and there was not a namespace in vAGen (imports/eGL Build Path).

    Anyway, the way the builder (actually we call it the compiler) works is that if a Top Level Function (TLF) is changed in a source file, then all the functions below it in the file are recompiled also.   Then if those functions were referenced in some other package/project, then those are rebuilt with the same processing in terms of position within a source file.     There are reasons we had to do "different" processing with TLFs mainly having to do with the fact that many times you want to validate them within the context of the program...not independently.

    As an example,  if you have a .egl source file that contains 100 Top Level Functions and you change the one that is physically the second one in the file.  When you save the file, it then rebuilds that function AND the following 98 functions.  If any of these 99 functions are referenced in the workspace (likely), then the build cascades to those functions to make sure all is still in sync..  Then it continues cascading until all references are rebuilt.    If you change the function that is physically the 98th one in the file, then it only rebuilds the 98, 99, and 100 functions and then cascades with this much smaller subset.

    All of this means a "simple" change in one top level function can trigger what looks like or could be the entire workspace being rebuilt...depending on how big the source files are with top level functions and what function was changed. .

    Now the good news is we did put a fix to help with performance in this scenario.   I don't believe it was shipped in 8.5.1 and therefore, it should be in 8.5.1.1 as well as 9.0.  It was originally shipped in 8.0.1.5.   (8.0.1.5 came after 8.5.1 if you are wondering..and this was a fix that originated in V8.0.1.

    The other option to look at is using EGLARs or Binary Projects.  Parts in an EGLAR are not rebuilt when a build is called for.  This will speed up the overall build time significantly.   It is a good practice to use particularly for common code.   V9.0 expanded our EGLAR support to allow the use of a libary (folder) to hold the EGLARs vs having to name each EGLAR individually.

    Mark

    Yes !

    I liked the answer! mainly on the part of the performance.

    Hsieh

  • mohaIBMDK
    mohaIBMDK
    25 Posts

    Re: RBD 8.51.0 - why doing alot of full "building workspace" ?

    ‏2013-09-21T06:20:01Z  
    • markevans
    • ‏2013-09-20T17:26:00Z

    Morten,

    If I understood your question, it is related to the length of time a "building Workspace" takes and why it is triggered so often.

    One reason could be related to how Top Level Functions (or also known as standalone functions)  are processed.   A top level function is a standalone function that is within a source file, but not contained in a program, library, or service (e.g. between the Program/end) .    It was a common practice for VAGen migrated functions since all functions in VAGen were essentially independent and there was not a namespace in vAGen (imports/eGL Build Path).

    Anyway, the way the builder (actually we call it the compiler) works is that if a Top Level Function (TLF) is changed in a source file, then all the functions below it in the file are recompiled also.   Then if those functions were referenced in some other package/project, then those are rebuilt with the same processing in terms of position within a source file.     There are reasons we had to do "different" processing with TLFs mainly having to do with the fact that many times you want to validate them within the context of the program...not independently.

    As an example,  if you have a .egl source file that contains 100 Top Level Functions and you change the one that is physically the second one in the file.  When you save the file, it then rebuilds that function AND the following 98 functions.  If any of these 99 functions are referenced in the workspace (likely), then the build cascades to those functions to make sure all is still in sync..  Then it continues cascading until all references are rebuilt.    If you change the function that is physically the 98th one in the file, then it only rebuilds the 98, 99, and 100 functions and then cascades with this much smaller subset.

    All of this means a "simple" change in one top level function can trigger what looks like or could be the entire workspace being rebuilt...depending on how big the source files are with top level functions and what function was changed. .

    Now the good news is we did put a fix to help with performance in this scenario.   I don't believe it was shipped in 8.5.1 and therefore, it should be in 8.5.1.1 as well as 9.0.  It was originally shipped in 8.0.1.5.   (8.0.1.5 came after 8.5.1 if you are wondering..and this was a fix that originated in V8.0.1.

    The other option to look at is using EGLARs or Binary Projects.  Parts in an EGLAR are not rebuilt when a build is called for.  This will speed up the overall build time significantly.   It is a good practice to use particularly for common code.   V9.0 expanded our EGLAR support to allow the use of a libary (folder) to hold the EGLARs vs having to name each EGLAR individually.

    Mark

    Hi Mark and Hsieh

    thanks for the reply to both of you.

    I think the building scenario, that Mark describes fits with our experience, and I have examined the fix list in 8.5.1.1 and it looks like my performance issue will be covered there.

    So - Ill try move to 8.5.1.1. Fingers crossed :-)

    Thanks again

    Morten