COMPILE with optimal PROPATH

Make sure that the PROPATH in use at the time you use the COMPILE statement have the source code folders available as the first folders. That's also true for the PROPATH used by OE Architect's syntax analysis.

We have a custom made ABL tool to compile our source code. Until now, the PROPATH used had some compiled files folders higher in the hierarchy than source file folders for a simple reason: the tool itself is written in ABL and we don't want it to be recompiled on the fly each time it is run.
We found that using an optimized PROPATH (only for the duration of the compilation - we put it back to normal after the compilation so that the tool can use the PROPATH it needs) increased the compilation speed dramatically in many cases, specially for source code files using many include files (note that a source file could include just one .i... but that this .i itself could well include many more .i files... as adm2 files, as SDOs, tend to do).

A quick peek with ProcessMonitor (from Microsoft) with the following test code showed that with the optimized PROPATH, there are many thousand less of file system accesses (QueryDirectory, QueryOpen, CreateFile + Read mode) resulting in PATH NOT FOND, NAME NOT FOND, NO SUCH FILE, NOT A DIRECTORY.

Note that this trick can also be used in OE Architect to speedup the code analysis time spent by Architect to be able to build its Outline view. In that case, put the optimized PROPATH as the PROPATH of the project and use different PROPATHs for Run Configurations (10.2A+) to be able to use compiled files folders first.

In the following sample, the optimized PROPATH made the compilation almost 75% faster than using our traditional PROPATH, enough to put a large smile on your face for a couple of minutes (results may vary according to your traditional and optimized PROPATH, in particular when local and network drives are used).

RUN CompileWithCurrentPropath.
RUN CompileWithCompilationPropath.

PROCEDURE CompileWithCurrentPropath:
  DEFINE VARIABLE i AS INTEGER NO-UNDO.
  
  ETIME(TRUE).
  
  DO i = 1 TO 5: /* 7874 ms */
    COMPILE src/adm2/smart.p.
  END.
  
  MESSAGE ETIME VIEW-AS ALERT-BOX.
END.

PROCEDURE CompileWithCompilationPropath:
  DEFINE VARIABLE cOldPropath AS CHARACTER NO-UNDO.
  DEFINE VARIABLE cDLCPath AS CHARACTER NO-UNDO.
  DEFINE VARIABLE i AS INTEGER NO-UNDO.
  
  GET-KEY-VALUE SECTION "Startup":U KEY "DLC":U VALUE cDLCPath.
  
  cOldPropath = PROPATH.
  PROPATH = cDLCPath.
  
  ETIME(TRUE).
  
  DO i = 1 TO 5: /* 2063 ms */
    COMPILE src/adm2/smart.p.
  END.
  
  MESSAGE ETIME VIEW-AS ALERT-BOX.

  PROPATH = cOldPropath.
END.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Full application compilation result

Our server, on which the source code resides, currently spends 34 min to do the compilation at night.

I tested this trick with our whole application (3975 compilable files - excludes .i) with my own machine (source code from a network drive instead of a local drive, less powerful processor and less RAM than our server) and I get a compilation time of 22 min.

35% faster: not bad! :c)

I'll post the new compilation time for our server when this modification goes live.


Compilation results for server

Last compilation before the optimization:
- 35m 03s for the generation of 3977 .r files

First compilation with the optimization:
- 20m 06s for the generation of 3991 .r files

That's ~43% faster compilation, with no adverse effect!

Imagine if we had that optimization in the AppBuilder era... all the time we lost because the compilation propath AppBuilder used was the same as the AppBuilder's execution propath...