[m-dev.] idea to speed up making trans_opt files

Zoltan Somogyi zoltan.somogyi at runbox.com
Mon Aug 5 18:59:04 AEST 2019



On Mon, 5 Aug 2019 14:42:26 +1000, Peter Wang <novalazy at gmail.com> wrote:
> I was reminding myself why making .trans_opt files in the library
> directory is a largely sequential process. There is a blob of cyclic
> dependencies in the standard library (67 modules). The cycle is broken
> arbitrarily by name: later modules can't use the .trans_opt files of
> earlier modules for the purposes of making a .trans_opt file.
> 
> I don't have a better idea for increasing parallelism in the process
> except, perhaps, manually removing a module's dependency on a particular
> .trans_opt file if we determine beforehand that the dependency will not
> (significantly) improve the results of the current module.

What I have long wanted was the ability to *visualise* the cyclic (and other)
dependencies graphically, with the info about *what* module A needs from
module B being available if you click on the arrow between them.
The compiler can now be asked to generate the info for the links;
the visualization part is still missing.

> To speed up the sequential process of making .trans_opt files:
> there probably is a lot of repeated work in reading and processing the
> same interface and .opt files since mmc is invoked to generate each
> .trans_opt separately. The obvious solution is to call mmc once with the
> set of modules it needs to generate .trans_opt files for, and have it
> retain the parsed/processed modules in memory across the set.
> 
> I'm not intending to work on this any time soon. Does it sound like a
> large change?

The compiler already has a mechanism for caching the parsed contents
of the files it has read, which it does not use very extensively. Extending
that mechanism for this use case should not be too difficult. But I would ask you
not to do this soon, as I am working on related code and such changes
will lead to conflicts.

The part about telling mmake to invoke a single command to build *all*
the .trans_opt files may be harder to do in a backward compatible fashion.
(I haven't worked on make code for a while, and my make-fu is on the fritz :-)

Zoltan.


More information about the developers mailing list